2010-06-09 00:52:24 +08:00
|
|
|
//===-- ValueObjectChild.cpp ------------------------------------*- C++ -*-===//
|
|
|
|
|
//
|
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
|
//
|
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
#include "lldb/Core/ValueObjectChild.h"
|
|
|
|
|
|
|
|
|
|
#include "lldb/Core/Module.h"
|
|
|
|
|
#include "lldb/Core/ValueObjectList.h"
|
|
|
|
|
|
2010-07-22 06:12:05 +08:00
|
|
|
#include "lldb/Symbol/ClangASTType.h"
|
2010-06-09 00:52:24 +08:00
|
|
|
#include "lldb/Symbol/ObjectFile.h"
|
|
|
|
|
#include "lldb/Symbol/SymbolContext.h"
|
|
|
|
|
#include "lldb/Symbol/Type.h"
|
|
|
|
|
#include "lldb/Symbol/Variable.h"
|
|
|
|
|
|
|
|
|
|
#include "lldb/Target/ExecutionContext.h"
|
|
|
|
|
#include "lldb/Target/Process.h"
|
|
|
|
|
#include "lldb/Target/Target.h"
|
|
|
|
|
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
|
|
|
|
ValueObjectChild::ValueObjectChild
|
|
|
|
|
(
|
2011-03-31 08:19:25 +08:00
|
|
|
ValueObject &parent,
|
2010-06-09 00:52:24 +08:00
|
|
|
clang::ASTContext *clang_ast,
|
|
|
|
|
void *clang_type,
|
|
|
|
|
const ConstString &name,
|
|
|
|
|
uint32_t byte_size,
|
|
|
|
|
int32_t byte_offset,
|
|
|
|
|
uint32_t bitfield_bit_size,
|
2010-10-15 06:52:14 +08:00
|
|
|
uint32_t bitfield_bit_offset,
|
2011-01-21 09:59:00 +08:00
|
|
|
bool is_base_class,
|
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 is_deref_of_parent,
|
|
|
|
|
AddressType child_ptr_or_ref_addr_type
|
2010-06-09 00:52:24 +08:00
|
|
|
) :
|
2010-10-15 06:52:14 +08:00
|
|
|
ValueObject (parent),
|
2010-06-09 00:52:24 +08:00
|
|
|
m_clang_ast (clang_ast),
|
|
|
|
|
m_clang_type (clang_type),
|
|
|
|
|
m_byte_size (byte_size),
|
|
|
|
|
m_byte_offset (byte_offset),
|
|
|
|
|
m_bitfield_bit_size (bitfield_bit_size),
|
2010-10-15 06:52:14 +08:00
|
|
|
m_bitfield_bit_offset (bitfield_bit_offset),
|
2011-01-21 09:59:00 +08:00
|
|
|
m_is_base_class (is_base_class),
|
|
|
|
|
m_is_deref_of_parent (is_deref_of_parent)
|
2010-06-09 00:52:24 +08:00
|
|
|
{
|
|
|
|
|
m_name = name;
|
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
|
|
|
SetAddressTypeOfChildren(child_ptr_or_ref_addr_type);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ValueObjectChild::~ValueObjectChild()
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
lldb::ValueType
|
|
|
|
|
ValueObjectChild::GetValueType() const
|
|
|
|
|
{
|
|
|
|
|
return m_parent->GetValueType();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
uint32_t
|
|
|
|
|
ValueObjectChild::CalculateNumChildren()
|
|
|
|
|
{
|
A few of the issue I have been trying to track down and fix have been due to
the way LLDB lazily gets complete definitions for types within the debug info.
When we run across a class/struct/union definition in the DWARF, we will only
parse the full definition if we need to. This works fine for top level types
that are assigned directly to variables and arguments, but when we have a
variable with a class, lets say "A" for this example, that has a member:
"B *m_b". Initially we don't need to hunt down a definition for this class
unless we are ever asked to do something with it ("expr m_b->getDecl()" for
example). With my previous approach to lazy type completion, we would be able
to take a "A *a" and get a complete type for it, but we wouldn't be able to
then do an "a->m_b->getDecl()" unless we always expanded all types within a
class prior to handing out the type. Expanding everything is very costly and
it would be great if there were a better way.
A few months ago I worked with the llvm/clang folks to have the
ExternalASTSource class be able to complete classes if there weren't completed
yet:
class ExternalASTSource {
....
virtual void
CompleteType (clang::TagDecl *Tag);
virtual void
CompleteType (clang::ObjCInterfaceDecl *Class);
};
This was great, because we can now have the class that is producing the AST
(SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources
and the object that creates the forward declaration types can now also
complete them anywhere within the clang type system.
This patch makes a few major changes:
- lldb_private::Module classes now own the AST context. Previously the TypeList
objects did.
- The DWARF parsers now sign up as an external AST sources so they can complete
types.
- All of the pure clang type system wrapper code we have in LLDB (ClangASTContext,
ClangASTType, and more) can now be iterating through children of any type,
and if a class/union/struct type (clang::RecordType or ObjC interface)
is found that is incomplete, we can ask the AST to get the definition.
- The SymbolFileDWARFDebugMap class now will create and use a single AST that
all child SymbolFileDWARF classes will share (much like what happens when
we have a complete linked DWARF for an executable).
We will need to modify some of the ClangUserExpression code to take more
advantage of this completion ability in the near future. Meanwhile we should
be better off now that we can be accessing any children of variables through
pointers and always be able to resolve the clang type if needed.
llvm-svn: 123613
2011-01-17 11:46:26 +08:00
|
|
|
return ClangASTContext::GetNumChildren (GetClangAST (), m_clang_type, true);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ConstString
|
|
|
|
|
ValueObjectChild::GetTypeName()
|
|
|
|
|
{
|
|
|
|
|
if (m_type_name.IsEmpty())
|
|
|
|
|
{
|
2011-06-30 10:28:26 +08:00
|
|
|
m_type_name = ClangASTType::GetConstTypeName (GetClangType());
|
2010-06-09 00:52:24 +08:00
|
|
|
if (m_type_name)
|
|
|
|
|
{
|
|
|
|
|
if (m_bitfield_bit_size > 0)
|
|
|
|
|
{
|
|
|
|
|
const char *clang_type_name = m_type_name.AsCString();
|
|
|
|
|
if (clang_type_name)
|
|
|
|
|
{
|
2010-07-10 04:39:50 +08:00
|
|
|
std::vector<char> bitfield_type_name (strlen(clang_type_name) + 32, 0);
|
2010-07-21 06:52:08 +08:00
|
|
|
::snprintf (&bitfield_type_name.front(), bitfield_type_name.size(), "%s:%u", clang_type_name, m_bitfield_bit_size);
|
|
|
|
|
m_type_name.SetCString(&bitfield_type_name.front());
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return m_type_name;
|
|
|
|
|
}
|
|
|
|
|
|
2011-03-31 08:19:25 +08:00
|
|
|
bool
|
|
|
|
|
ValueObjectChild::UpdateValue ()
|
2010-06-09 00:52:24 +08:00
|
|
|
{
|
|
|
|
|
m_error.Clear();
|
|
|
|
|
SetValueIsValid (false);
|
|
|
|
|
ValueObject* parent = m_parent;
|
|
|
|
|
if (parent)
|
|
|
|
|
{
|
2011-08-03 01:27:39 +08:00
|
|
|
if (parent->UpdateValueIfNeeded(false))
|
2010-06-09 00:52:24 +08:00
|
|
|
{
|
2010-11-13 11:52:47 +08:00
|
|
|
m_value.SetContext(Value::eContextTypeClangType, m_clang_type);
|
2010-06-09 00:52:24 +08:00
|
|
|
|
|
|
|
|
// Copy the parent scalar value and the scalar value type
|
|
|
|
|
m_value.GetScalar() = parent->GetValue().GetScalar();
|
|
|
|
|
Value::ValueType value_type = parent->GetValue().GetValueType();
|
|
|
|
|
m_value.SetValueType (value_type);
|
|
|
|
|
|
2010-09-29 09:12:09 +08:00
|
|
|
if (ClangASTContext::IsPointerOrReferenceType (parent->GetClangType()))
|
2010-06-09 00:52:24 +08:00
|
|
|
{
|
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
|
|
|
lldb::addr_t addr = parent->GetPointerValue ();
|
2011-08-16 08:44:29 +08:00
|
|
|
m_value.GetScalar() = addr;
|
2010-11-02 09:50:16 +08:00
|
|
|
|
|
|
|
|
if (addr == LLDB_INVALID_ADDRESS)
|
|
|
|
|
{
|
|
|
|
|
m_error.SetErrorString ("parent address is invalid.");
|
|
|
|
|
}
|
|
|
|
|
else if (addr == 0)
|
|
|
|
|
{
|
|
|
|
|
m_error.SetErrorString ("parent is NULL");
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
2010-11-03 05:21:20 +08:00
|
|
|
m_value.GetScalar() += m_byte_offset;
|
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
|
|
|
AddressType addr_type = parent->GetAddressTypeOfChildren();
|
|
|
|
|
|
|
|
|
|
switch (addr_type)
|
|
|
|
|
{
|
|
|
|
|
case eAddressTypeFile:
|
|
|
|
|
if (m_update_point.GetProcessSP().get() != NULL && m_update_point.GetProcessSP()->IsAlive() == true)
|
|
|
|
|
m_value.SetValueType (Value::eValueTypeLoadAddress);
|
|
|
|
|
else
|
|
|
|
|
m_value.SetValueType(Value::eValueTypeFileAddress);
|
|
|
|
|
break;
|
|
|
|
|
case eAddressTypeLoad:
|
|
|
|
|
m_value.SetValueType (Value::eValueTypeLoadAddress);
|
|
|
|
|
break;
|
|
|
|
|
case eAddressTypeHost:
|
|
|
|
|
m_value.SetValueType(Value::eValueTypeHostAddress);
|
|
|
|
|
break;
|
|
|
|
|
case eAddressTypeInvalid:
|
|
|
|
|
default:
|
|
|
|
|
// TODO: does this make sense?
|
|
|
|
|
m_value.SetValueType(Value::eValueTypeScalar);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2010-11-02 09:50:16 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
switch (value_type)
|
|
|
|
|
{
|
|
|
|
|
case Value::eValueTypeLoadAddress:
|
|
|
|
|
case Value::eValueTypeFileAddress:
|
|
|
|
|
case Value::eValueTypeHostAddress:
|
|
|
|
|
{
|
|
|
|
|
lldb::addr_t addr = m_value.GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
|
2010-11-02 09:50:16 +08:00
|
|
|
if (addr == LLDB_INVALID_ADDRESS)
|
|
|
|
|
{
|
|
|
|
|
m_error.SetErrorString ("parent address is invalid.");
|
|
|
|
|
}
|
|
|
|
|
else if (addr == 0)
|
|
|
|
|
{
|
|
|
|
|
m_error.SetErrorString ("parent is NULL");
|
|
|
|
|
}
|
|
|
|
|
else
|
2010-06-09 00:52:24 +08:00
|
|
|
{
|
2010-11-02 09:50:16 +08:00
|
|
|
// Set this object's scalar value to the address of its
|
2011-08-13 07:34:31 +08:00
|
|
|
// value by adding its byte offset to the parent address
|
2010-11-02 09:50:16 +08:00
|
|
|
m_value.GetScalar() += GetByteOffset();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case Value::eValueTypeScalar:
|
|
|
|
|
// TODO: What if this is a register value? Do we try and
|
|
|
|
|
// extract the child value from within the parent data?
|
|
|
|
|
// Probably...
|
|
|
|
|
default:
|
2011-10-26 08:56:27 +08:00
|
|
|
m_error.SetErrorString ("parent has invalid value.");
|
2010-06-09 00:52:24 +08:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (m_error.Success())
|
|
|
|
|
{
|
2011-03-31 08:19:25 +08:00
|
|
|
ExecutionContext exe_ctx (GetExecutionContextScope());
|
2011-07-07 09:59:51 +08:00
|
|
|
m_error = m_value.GetValueAsData (&exe_ctx, GetClangAST (), m_data, 0, GetModule());
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
2011-10-26 08:56:27 +08:00
|
|
|
m_error.SetErrorStringWithFormat("parent failed to evaluate: %s", parent->GetError().AsCString());
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
m_error.SetErrorString("ValueObjectChild has a NULL parent ValueObject.");
|
|
|
|
|
}
|
2011-03-31 08:19:25 +08:00
|
|
|
|
|
|
|
|
return m_error.Success();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bool
|
2011-03-31 08:19:25 +08:00
|
|
|
ValueObjectChild::IsInScope ()
|
2010-06-09 00:52:24 +08:00
|
|
|
{
|
2011-03-31 08:19:25 +08:00
|
|
|
return m_parent->IsInScope ();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|