Adding new API calls to SBValue to be able to retrieve the associated formatters
Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed)
Test cases added for the above
llvm-svn: 150784
to find Objective-C class types by looking in the
symbol tables for the individual object files.
I did this as follows:
- I added code to SymbolFileSymtab that vends
Clang types for symbols matching the pattern
"_OBJC_CLASS_$_NSMyClassName," making them
appear as Objective-C classes. This only occurs
in modules that do not have debug information,
since otherwise SymbolFileDWARF would be in
charge of looking up types.
- I made a new SymbolVendor subclass for the
Apple Objective-C runtime that is in charge of
making global lookups of Objective-C types. It
currently just sends out type lookup requests to
the appropriate SymbolFiles, but in the future we
will probably extend it to query the runtime more
completely.
I also modified a testcase whose behavior is changed
by the fact that we now actually return an Objective-C
type for __NSCFString.
llvm-svn: 145526
it to generate result variables that were not bound
to their underlying data. This allowed the SBValue
class to use the interpreter (if possible).
Also made sure that any result variables that point
to stack allocations in the stack frame of the
interpreted expressions do not get live data.
llvm-svn: 140285
Access to synthetic children by name:
if your object has a synthetic child named foo you can now type
frame variable object.foo (or ->foo if you have a pointer)
and that will print the value of the synthetic child
(if your object has an actual child named foo, the actual child prevails!)
this behavior should also work in summaries, and you should be able to use
${var.foo} and ${svar.foo} interchangeably
(but using svar.foo will mask an actual child named foo)
llvm-svn: 137314
new --raw-output (-R) option to frame variable prevents using summaries and synthetic children
other future formatting enhancements will be excluded by using the -R option
test case enhanced to check that -R works correctly
llvm-svn: 137185
The synthetic children providers now use the new (safer) APIs to get the values of objects
As a side effect, fixed an issue in ValueObject where ResolveValue() was not always updating the value before reading it
llvm-svn: 136861
- see the test case in lang/objc/objc-dynamic-value for an example
Objective-C dynamic type lookup now works for every Objective-C type
- previously, true dynamic lookup was only performed for type id
llvm-svn: 136763
Fixed a bug where Objective-C variables coming out of the expression parser could crash the Python synthetic providers:
- expression parser output has a "frozen data" component, which is a byte-exact copy of the value (in host memory),
if trying to read into memory based on the host address, LLDB would crash. we are now passing the correct (target)
pointer to the Python code
Objective-C "id" variables are now formatted according to their dynamic type, if the -d option to frame variable is used:
- Code based on the Objective-C 2.0 runtime is used to obtain this information without running code on the target
llvm-svn: 136695
Enrico Granata