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

1 files changed, 26 insertions, 9 deletions

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