Files
clang-p2996/lldb/test/expression_command/formatters/main.cpp
Enrico Granata 9128ee2f7a 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-06 19:20:51 +00:00

48 lines
627 B
C++

#include <iostream>
#include <string>
struct baz
{
int h;
int k;
baz(int a, int b) : h(a), k(b) {}
};
struct bar
{
int i;
int* i_ptr;
baz b;
baz& b_ref;
bar(int x) : i(x),i_ptr(new int(x+1)),b(i+3,i+5),b_ref(b) {}
};
struct foo
{
int a;
int* a_ptr;
bar b;
foo(int x) : a(x),
a_ptr(new int(x+1)),
b(2*x) {}
};
int main(int argc, char** argv)
{
foo foo1(12);
foo foo2(121);
foo2.a = 7777; // Stop here
*(foo2.b.i_ptr) = 8888;
foo2.b.b.h = 9999;
*(foo1.a_ptr) = 9999;
foo1.b.i = 9999;
int numbers[5] = {1,2,3,4,5};
return 0;
}