llvm-project/lldb/source/Core/ValueObjectVariable.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

415 lines
15 KiB
C++
Raw Normal View History

//===-- ValueObjectVariable.cpp -------------------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
#include "lldb/Core/ValueObjectVariable.h"
#include "lldb/Core/Address.h"
#include "lldb/Core/AddressRange.h"
#include "lldb/Core/Declaration.h"
#include "lldb/Core/Module.h"
#include "lldb/Core/Value.h"
#include "lldb/Expression/DWARFExpression.h"
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-30 05:13:06 +08:00
#include "lldb/Symbol/Function.h"
#include "lldb/Symbol/ObjectFile.h"
#include "lldb/Symbol/SymbolContext.h"
#include "lldb/Symbol/SymbolContextScope.h"
#include "lldb/Symbol/Type.h"
#include "lldb/Symbol/Variable.h"
#include "lldb/Target/ExecutionContext.h"
#include "lldb/Target/Process.h"
#include "lldb/Target/RegisterContext.h"
#include "lldb/Target/Target.h"
#include "lldb/Utility/DataExtractor.h"
#include "lldb/Utility/RegisterValue.h"
#include "lldb/Utility/Scalar.h"
#include "lldb/Utility/Status.h"
#include "lldb/lldb-private-enumerations.h"
#include "lldb/lldb-types.h"
#include "llvm/ADT/StringRef.h"
#include <cassert>
#include <memory>
namespace lldb_private {
class ExecutionContextScope;
}
namespace lldb_private {
class StackFrame;
}
namespace lldb_private {
struct RegisterInfo;
}
using namespace lldb_private;
lldb::ValueObjectSP
ValueObjectVariable::Create(ExecutionContextScope *exe_scope,
const lldb::VariableSP &var_sp) {
auto manager_sp = ValueObjectManager::Create();
return (new ValueObjectVariable(exe_scope, *manager_sp, var_sp))->GetSP();
}
ValueObjectVariable::ValueObjectVariable(ExecutionContextScope *exe_scope,
ValueObjectManager &manager,
const lldb::VariableSP &var_sp)
: ValueObject(exe_scope, manager), m_variable_sp(var_sp) {
// Do not attempt to construct one of these objects with no variable!
assert(m_variable_sp.get() != nullptr);
m_name = var_sp->GetName();
}
ValueObjectVariable::~ValueObjectVariable() = default;
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-25 07:46:31 +08:00
CompilerType ValueObjectVariable::GetCompilerTypeImpl() {
Type *var_type = m_variable_sp->GetType();
if (var_type)
return var_type->GetForwardCompilerType();
return CompilerType();
}
ConstString ValueObjectVariable::GetTypeName() {
Type *var_type = m_variable_sp->GetType();
if (var_type)
return var_type->GetName();
return ConstString();
}
Introduce the concept of a "display name" for types Rationale: Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as std::__1::vector<int, std::__1::allocator<.... rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code Proposed solution: Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type Caveats: - for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet. - while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters llvm-svn: 209072
2014-05-18 03:14:17 +08:00
ConstString ValueObjectVariable::GetDisplayTypeName() {
Type *var_type = m_variable_sp->GetType();
if (var_type)
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-25 07:46:31 +08:00
return var_type->GetForwardCompilerType().GetDisplayTypeName();
Introduce the concept of a "display name" for types Rationale: Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as std::__1::vector<int, std::__1::allocator<.... rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code Proposed solution: Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type Caveats: - for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet. - while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters llvm-svn: 209072
2014-05-18 03:14:17 +08:00
return ConstString();
}
ConstString ValueObjectVariable::GetQualifiedTypeName() {
Type *var_type = m_variable_sp->GetType();
if (var_type)
return var_type->GetQualifiedName();
return ConstString();
}
size_t ValueObjectVariable::CalculateNumChildren(uint32_t max) {
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-25 07:46:31 +08:00
CompilerType type(GetCompilerType());
if (!type.IsValid())
return 0;
ExecutionContext exe_ctx(GetExecutionContextRef());
const bool omit_empty_base_classes = true;
auto child_count = type.GetNumChildren(omit_empty_base_classes, &exe_ctx);
return child_count <= max ? child_count : max;
}
llvm::Optional<uint64_t> ValueObjectVariable::GetByteSize() {
ExecutionContext exe_ctx(GetExecutionContextRef());
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-25 07:46:31 +08:00
CompilerType type(GetCompilerType());
if (!type.IsValid())
return {};
return type.GetByteSize(exe_ctx.GetBestExecutionContextScope());
}
lldb::ValueType ValueObjectVariable::GetValueType() const {
if (m_variable_sp)
return m_variable_sp->GetScope();
return lldb::eValueTypeInvalid;
}
bool ValueObjectVariable::UpdateValue() {
SetValueIsValid(false);
m_error.Clear();
2011-05-30 08:49:24 +08:00
Variable *variable = m_variable_sp.get();
DWARFExpression &expr = variable->LocationExpression();
2011-05-30 08:49:24 +08:00
if (variable->GetLocationIsConstantValueData()) {
2011-05-30 08:49:24 +08:00
// expr doesn't contain DWARF bytes, it contains the constant variable
// value bytes themselves...
if (expr.GetExpressionData(m_data)) {
if (m_data.GetDataStart() && m_data.GetByteSize())
m_value.SetBytes(m_data.GetDataStart(), m_data.GetByteSize());
m_value.SetContext(Value::ContextType::Variable, variable);
}
else
2011-05-30 08:49:24 +08:00
m_error.SetErrorString("empty constant data");
// constant bytes can't be edited - sorry
m_resolved_value.SetContext(Value::ContextType::Invalid, nullptr);
} else {
lldb::addr_t loclist_base_load_addr = LLDB_INVALID_ADDRESS;
2011-05-30 08:49:24 +08:00
ExecutionContext exe_ctx(GetExecutionContextRef());
2011-05-30 08:49:24 +08:00
Target *target = exe_ctx.GetTargetPtr();
if (target) {
m_data.SetByteOrder(target->GetArchitecture().GetByteOrder());
m_data.SetAddressByteSize(target->GetArchitecture().GetAddressByteSize());
}
2011-05-30 08:49:24 +08:00
if (expr.IsLocationList()) {
SymbolContext sc;
variable->CalculateSymbolContext(&sc);
if (sc.function)
loclist_base_load_addr =
sc.function->GetAddressRange().GetBaseAddress().GetLoadAddress(
target);
}
2011-05-30 08:49:24 +08:00
Value old_value(m_value);
if (expr.Evaluate(&exe_ctx, nullptr, loclist_base_load_addr, nullptr,
nullptr, m_value, &m_error)) {
m_resolved_value = m_value;
m_value.SetContext(Value::ContextType::Variable, variable);
CompilerType compiler_type = GetCompilerType();
if (compiler_type.IsValid())
m_value.SetCompilerType(compiler_type);
2011-05-30 08:49:24 +08:00
Value::ValueType value_type = m_value.GetValueType();
[lldb/Value] Avoid reading more data than the host has available Value::GetValueByteSize() reports the size of a Value as the size of its underlying CompilerType. However, a host buffer that backs a Value may be smaller than GetValueByteSize(). This situation arises when the host is only able to partially evaluate a Value, e.g. because the expression contains DW_OP_piece. The cleanest fix I've found to this problem is Greg's suggestion, which is to resize the Value if (after evaluating an expression) it's found to be too small. I've tried several alternatives which all (in one way or the other) tried to teach the Value/ValueObjectChild system not to read past the end of a host buffer, but this was flaky and impractical as it isn't easy to figure out the host buffer's size (Value::GetScalar() can point to somewhere /inside/ a host buffer, but you need to walk up the ValueObject hierarchy to try and find its size). This fixes an ASan error in lldb seen when debugging a clang binary. I've added a regression test in test/functionalities/optimized_code. The point of that test is not specifically to check that DW_OP_piece is handled a particular way, but rather to check that lldb doesn't crash on an input that it used to crash on. Testing: check-lldb, and running the added tests using a sanitized lldb -- Thanks to Jim for pointing out that an earlier version of this patch, which simply changed the definition of Value::GetValueByteSize(), would interact poorly with the ValueObject machinery. Thanks also to Pavel who suggested a neat way to test this change (which, incidentally, caught another ASan issue still present in the original version of this patch). rdar://58665925 Differential Revision: https://reviews.llvm.org/D73148
2020-01-22 08:01:16 +08:00
// The size of the buffer within m_value can be less than the size
// prescribed by its type. E.g. this can happen when an expression only
// partially describes an object (say, because it contains DW_OP_piece).
//
// In this case, grow m_value to the expected size. An alternative way to
// handle this is to teach Value::GetValueAsData() and ValueObjectChild
// not to read past the end of a host buffer, but this gets impractically
// complicated as a Value's host buffer may be shared with a distant
// ancestor or sibling in the ValueObject hierarchy.
//
// FIXME: When we grow m_value, we should represent the added bits as
// undefined somehow instead of as 0's.
if (value_type == Value::ValueType::HostAddress &&
[lldb/Value] Avoid reading more data than the host has available Value::GetValueByteSize() reports the size of a Value as the size of its underlying CompilerType. However, a host buffer that backs a Value may be smaller than GetValueByteSize(). This situation arises when the host is only able to partially evaluate a Value, e.g. because the expression contains DW_OP_piece. The cleanest fix I've found to this problem is Greg's suggestion, which is to resize the Value if (after evaluating an expression) it's found to be too small. I've tried several alternatives which all (in one way or the other) tried to teach the Value/ValueObjectChild system not to read past the end of a host buffer, but this was flaky and impractical as it isn't easy to figure out the host buffer's size (Value::GetScalar() can point to somewhere /inside/ a host buffer, but you need to walk up the ValueObject hierarchy to try and find its size). This fixes an ASan error in lldb seen when debugging a clang binary. I've added a regression test in test/functionalities/optimized_code. The point of that test is not specifically to check that DW_OP_piece is handled a particular way, but rather to check that lldb doesn't crash on an input that it used to crash on. Testing: check-lldb, and running the added tests using a sanitized lldb -- Thanks to Jim for pointing out that an earlier version of this patch, which simply changed the definition of Value::GetValueByteSize(), would interact poorly with the ValueObject machinery. Thanks also to Pavel who suggested a neat way to test this change (which, incidentally, caught another ASan issue still present in the original version of this patch). rdar://58665925 Differential Revision: https://reviews.llvm.org/D73148
2020-01-22 08:01:16 +08:00
compiler_type.IsValid()) {
if (size_t value_buf_size = m_value.GetBuffer().GetByteSize()) {
size_t value_size = m_value.GetValueByteSize(&m_error, &exe_ctx);
if (m_error.Success() && value_buf_size < value_size)
m_value.ResizeData(value_size);
}
}
Process *process = exe_ctx.GetProcessPtr();
const bool process_is_alive = process && process->IsAlive();
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
switch (value_type) {
case Value::ValueType::Invalid:
m_error.SetErrorString("invalid value");
break;
case Value::ValueType::Scalar:
// The variable value is in the Scalar value inside the m_value. We can
// point our m_data right to it.
m_error =
m_value.GetValueAsData(&exe_ctx, m_data, GetModule().get());
break;
case Value::ValueType::FileAddress:
case Value::ValueType::LoadAddress:
case Value::ValueType::HostAddress:
// The DWARF expression result was an address in the inferior process.
// If this variable is an aggregate type, we just need the address as
// the main value as all child variable objects will rely upon this
// location and add an offset and then read their own values as needed.
// If this variable is a simple type, we read all data for it into
// m_data. Make sure this type has a value before we try and read it
// If we have a file address, convert it to a load address if we can.
if (value_type == Value::ValueType::FileAddress && process_is_alive)
m_value.ConvertToLoadAddress(GetModule().get(), target);
if (!CanProvideValue()) {
// this value object represents an aggregate type whose children have
// values, but this object does not. So we say we are changed if our
// location has changed.
SetValueDidChange(value_type != old_value.GetValueType() ||
m_value.GetScalar() != old_value.GetScalar());
} else {
// Copy the Value and set the context to use our Variable so it can
// extract read its value into m_data appropriately
2011-05-30 08:49:24 +08:00
Value value(m_value);
value.SetContext(Value::ContextType::Variable, variable);
m_error =
value.GetValueAsData(&exe_ctx, m_data, GetModule().get());
2011-05-30 08:49:24 +08:00
SetValueDidChange(value_type != old_value.GetValueType() ||
m_value.GetScalar() != old_value.GetScalar());
}
break;
}
2011-05-30 08:49:24 +08:00
SetValueIsValid(m_error.Success());
} else {
// could not find location, won't allow editing
m_resolved_value.SetContext(Value::ContextType::Invalid, nullptr);
}
}
return m_error.Success();
}
void ValueObjectVariable::DoUpdateChildrenAddressType(ValueObject &valobj) {
Value::ValueType value_type = valobj.GetValue().GetValueType();
ExecutionContext exe_ctx(GetExecutionContextRef());
Process *process = exe_ctx.GetProcessPtr();
const bool process_is_alive = process && process->IsAlive();
const uint32_t type_info = valobj.GetCompilerType().GetTypeInfo();
const bool is_pointer_or_ref =
(type_info & (lldb::eTypeIsPointer | lldb::eTypeIsReference)) != 0;
switch (value_type) {
case Value::ValueType::Invalid:
break;
case Value::ValueType::FileAddress:
// If this type is a pointer, then its children will be considered load
// addresses if the pointer or reference is dereferenced, but only if
// the process is alive.
//
// There could be global variables like in the following code:
// struct LinkedListNode { Foo* foo; LinkedListNode* next; };
// Foo g_foo1;
// Foo g_foo2;
// LinkedListNode g_second_node = { &g_foo2, NULL };
// LinkedListNode g_first_node = { &g_foo1, &g_second_node };
//
// When we aren't running, we should be able to look at these variables
// using the "target variable" command. Children of the "g_first_node"
// always will be of the same address type as the parent. But children
// of the "next" member of LinkedListNode will become load addresses if
// we have a live process, or remain a file address if it was a file
// address.
if (process_is_alive && is_pointer_or_ref)
valobj.SetAddressTypeOfChildren(eAddressTypeLoad);
else
valobj.SetAddressTypeOfChildren(eAddressTypeFile);
break;
case Value::ValueType::HostAddress:
// Same as above for load addresses, except children of pointer or refs
// are always load addresses. Host addresses are used to store freeze
// dried variables. If this type is a struct, the entire struct
// contents will be copied into the heap of the
// LLDB process, but we do not currently follow any pointers.
if (is_pointer_or_ref)
valobj.SetAddressTypeOfChildren(eAddressTypeLoad);
else
valobj.SetAddressTypeOfChildren(eAddressTypeHost);
break;
case Value::ValueType::LoadAddress:
case Value::ValueType::Scalar:
valobj.SetAddressTypeOfChildren(eAddressTypeLoad);
break;
}
}
bool ValueObjectVariable::IsInScope() {
const ExecutionContextRef &exe_ctx_ref = GetExecutionContextRef();
if (exe_ctx_ref.HasFrameRef()) {
ExecutionContext exe_ctx(exe_ctx_ref);
StackFrame *frame = exe_ctx.GetFramePtr();
if (frame) {
return m_variable_sp->IsInScope(frame);
} else {
// This ValueObject had a frame at one time, but now we can't locate it,
// so return false since we probably aren't in scope.
return false;
}
}
// We have a variable that wasn't tied to a frame, which means it is a global
// and is always in scope.
return true;
}
lldb::ModuleSP ValueObjectVariable::GetModule() {
if (m_variable_sp) {
SymbolContextScope *sc_scope = m_variable_sp->GetSymbolContextScope();
if (sc_scope) {
return sc_scope->CalculateSymbolContextModule();
}
}
return lldb::ModuleSP();
}
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
SymbolContextScope *ValueObjectVariable::GetSymbolContextScope() {
if (m_variable_sp)
return m_variable_sp->GetSymbolContextScope();
return nullptr;
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
}
bool ValueObjectVariable::GetDeclaration(Declaration &decl) {
if (m_variable_sp) {
decl = m_variable_sp->GetDeclaration();
return true;
}
return false;
}
const char *ValueObjectVariable::GetLocationAsCString() {
if (m_resolved_value.GetContextType() == Value::ContextType::RegisterInfo)
return GetLocationAsCStringImpl(m_resolved_value, m_data);
else
return ValueObject::GetLocationAsCString();
}
bool ValueObjectVariable::SetValueFromCString(const char *value_str,
Status &error) {
if (!UpdateValueIfNeeded()) {
error.SetErrorString("unable to update value before writing");
return false;
}
if (m_resolved_value.GetContextType() == Value::ContextType::RegisterInfo) {
RegisterInfo *reg_info = m_resolved_value.GetRegisterInfo();
ExecutionContext exe_ctx(GetExecutionContextRef());
RegisterContext *reg_ctx = exe_ctx.GetRegisterContext();
RegisterValue reg_value;
if (!reg_info || !reg_ctx) {
error.SetErrorString("unable to retrieve register info");
return false;
}
error = reg_value.SetValueFromString(reg_info, llvm::StringRef(value_str));
if (error.Fail())
return false;
if (reg_ctx->WriteRegister(reg_info, reg_value)) {
SetNeedsUpdate();
return true;
} else {
error.SetErrorString("unable to write back to register");
return false;
}
} else
return ValueObject::SetValueFromCString(value_str, error);
}
bool ValueObjectVariable::SetData(DataExtractor &data, Status &error) {
if (!UpdateValueIfNeeded()) {
error.SetErrorString("unable to update value before writing");
return false;
}
if (m_resolved_value.GetContextType() == Value::ContextType::RegisterInfo) {
RegisterInfo *reg_info = m_resolved_value.GetRegisterInfo();
ExecutionContext exe_ctx(GetExecutionContextRef());
RegisterContext *reg_ctx = exe_ctx.GetRegisterContext();
RegisterValue reg_value;
if (!reg_info || !reg_ctx) {
error.SetErrorString("unable to retrieve register info");
return false;
}
error = reg_value.SetValueFromData(reg_info, data, 0, true);
if (error.Fail())
return false;
if (reg_ctx->WriteRegister(reg_info, reg_value)) {
SetNeedsUpdate();
return true;
} else {
error.SetErrorString("unable to write back to register");
return false;
}
} else
return ValueObject::SetData(data, error);
}