From 9128ee2f7accbb6225858416c8a956e6102b86b8 Mon Sep 17 00:00:00 2001 From: Enrico Granata Date: Tue, 6 Sep 2011 19:20:51 +0000 Subject: 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 --- lldb/source/Core/ValueObjectChild.cpp | 35 ++++++++++++++++++++++++++--------- 1 file changed, 26 insertions(+), 9 deletions(-) (limited to 'lldb/source/Core/ValueObjectChild.cpp') diff --git a/lldb/source/Core/ValueObjectChild.cpp b/lldb/source/Core/ValueObjectChild.cpp index 4075f60ebb3..b07b38c7544 100644 --- a/lldb/source/Core/ValueObjectChild.cpp +++ b/lldb/source/Core/ValueObjectChild.cpp @@ -35,7 +35,8 @@ ValueObjectChild::ValueObjectChild uint32_t bitfield_bit_size, uint32_t bitfield_bit_offset, bool is_base_class, - bool is_deref_of_parent + bool is_deref_of_parent, + AddressType child_ptr_or_ref_addr_type ) : ValueObject (parent), m_clang_ast (clang_ast), @@ -48,6 +49,7 @@ ValueObjectChild::ValueObjectChild m_is_deref_of_parent (is_deref_of_parent) { m_name = name; + SetAddressTypeOfChildren(child_ptr_or_ref_addr_type); } ValueObjectChild::~ValueObjectChild() @@ -108,10 +110,7 @@ ValueObjectChild::UpdateValue () if (ClangASTContext::IsPointerOrReferenceType (parent->GetClangType())) { - const bool scalar_is_load_address = true; - AddressType address_type; - - lldb::addr_t addr = parent->GetPointerValue (address_type, scalar_is_load_address); + lldb::addr_t addr = parent->GetPointerValue (); m_value.GetScalar() = addr; if (addr == LLDB_INVALID_ADDRESS) @@ -125,10 +124,28 @@ ValueObjectChild::UpdateValue () else { m_value.GetScalar() += m_byte_offset; - if (m_pointers_point_to_load_addrs || - value_type == Value::eValueTypeScalar || - value_type == Value::eValueTypeFileAddress) - m_value.SetValueType (Value::eValueTypeLoadAddress); + 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; + } } } else -- cgit v1.2.3