diff options
author | Enrico Granata <granata.enrico@gmail.com> | 2011-09-06 19:20:51 +0000 |
---|---|---|
committer | Enrico Granata <granata.enrico@gmail.com> | 2011-09-06 19:20:51 +0000 |
commit | 9128ee2f7accbb6225858416c8a956e6102b86b8 (patch) | |
tree | d2765b8f8ac9f66fe4232e016913c0313436b1ea /lldb/source/Plugins/OperatingSystem/Darwin-Kernel/OperatingSystemDarwinKernel.cpp | |
parent | f2641e1bc11b28db5722f7f6adec2ac416dd0f6c (diff) | |
download | bcm5719-llvm-9128ee2f7accbb6225858416c8a956e6102b86b8.tar.gz bcm5719-llvm-9128ee2f7accbb6225858416c8a956e6102b86b8.zip |
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
Diffstat (limited to 'lldb/source/Plugins/OperatingSystem/Darwin-Kernel/OperatingSystemDarwinKernel.cpp')
-rw-r--r-- | lldb/source/Plugins/OperatingSystem/Darwin-Kernel/OperatingSystemDarwinKernel.cpp | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/lldb/source/Plugins/OperatingSystem/Darwin-Kernel/OperatingSystemDarwinKernel.cpp b/lldb/source/Plugins/OperatingSystem/Darwin-Kernel/OperatingSystemDarwinKernel.cpp index 2fdd3b099b3..c5f3e40bd34 100644 --- a/lldb/source/Plugins/OperatingSystem/Darwin-Kernel/OperatingSystemDarwinKernel.cpp +++ b/lldb/source/Plugins/OperatingSystem/Darwin-Kernel/OperatingSystemDarwinKernel.cpp @@ -156,9 +156,9 @@ OperatingSystemDarwinKernel::GetDynamicRegisterInfo () ValueObjectSP gpr_valobj_sp (m_thread_list_valobj_sp->GetChildMemberWithName(GetThreadGPRMemberName (), can_create)); if (gpr_valobj_sp->IsPointerType ()) - base_addr = gpr_valobj_sp->GetPointerValue (addr_type, true); + base_addr = gpr_valobj_sp->GetPointerValue (&addr_type); else - base_addr = gpr_valobj_sp->GetAddressOf (addr_type, true); + base_addr = gpr_valobj_sp->GetAddressOf (true, &addr_type); ValueObjectSP child_valobj_sp; if (gpr_valobj_sp) @@ -188,7 +188,7 @@ OperatingSystemDarwinKernel::GetDynamicRegisterInfo () { // Adjust the byte size and the offset to match the layout of registers in our struct reg_info.byte_size = child_valobj_sp->GetByteSize(); - reg_info.byte_offset = child_valobj_sp->GetAddressOf(addr_type, true) - base_addr; + reg_info.byte_offset = child_valobj_sp->GetAddressOf(true, &addr_type) - base_addr; reg_info.kinds[eRegisterKindLLDB] = reg_num++; m_register_info_ap->AddRegister (reg_info, reg_name, empty_name, gpr_name); } @@ -290,9 +290,9 @@ OperatingSystemDarwinKernel::CreateRegisterContextForThread (Thread *thread) if (gpr_valobj_sp) { if (gpr_valobj_sp->IsPointerType ()) - base_addr = gpr_valobj_sp->GetPointerValue (addr_type, true); + base_addr = gpr_valobj_sp->GetPointerValue (&addr_type); else - base_addr = gpr_valobj_sp->GetAddressOf (addr_type, true); + base_addr = gpr_valobj_sp->GetAddressOf (true, &addr_type); reg_ctx_sp.reset (new RegisterContextMemory (*thread, 0, *GetDynamicRegisterInfo (), base_addr)); } } |