Fixed up many API calls to not be "const" as const doesn't mean anything to
most of our lldb::SB objects since they contain a shared pointer, auto_ptr, or
pointer to the types which circumvent the constness anyway.
llvm-svn: 139428
- 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
If you have a Python module foo, in order to use its contained objects in LLDB you do not need to use
'from foo import *'. You can use 'import foo', and then refer to items in foo as 'foo.bar', and LLDB
will know how to resolve bar as a member of foo.
Accordingly, GNU libstdc++ formatters have been moved from the global namespace to gnu_libstdcpp and a few
test cases are also updated to reflect the new convention. Python docs suggest using a plain 'import' en lieu of
'from-import'.
llvm-svn: 138244
- all instances of "vobj" have been renamed to "valobj"
- class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp)
The interface to this class has not changed
- FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting
from ConstString to const char* and back all the time
Next step is making the same happen for categories themselves
- category gnu-libstdc++ is defined in the constructor for a FormatManager
The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time
All references to previous 'osxcpp' name have been removed from both code and file names
Functional changes:
- the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string
to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script
will become -o
llvm-svn: 137886
The category is enabled by default. If you run into issues with it, disable it and the previous behavior of LLDB is restored
** This is a temporary solution. The general solution to having formatters pulled in at startup should involve going through the Platform.
Fixed an issue in type synthetic list where a category with synthetic providers in it was not shown if all the providers were regex-based
llvm-svn: 137850
- They now have an SBCommandReturnObject instead of an SBStream as third argument
- The class CommandObjectPythonFunction has been merged into CommandObjectCommands.cpp
- The command to manage them is now:
command script with subcommands add, list, delete, clear
command alias is returned to its previous functionality
- Python commands are now part of an user dictionary, instead of being seen as aliases
llvm-svn: 137785
It is now possible to use 'command alias --python' to define a command name that actually triggers execution of a Python function
(e.g. command alias --python foo foo_impl makes a command named 'foo' that runs Python function 'foo_impl')
The Python function foo_impl should have as signature: def foo_impl(debugger, args, stream, dict): where
debugger is an object wrapping an LLDB SBDebugger
args is the command line arguments, as an unparsed Python string
stream is an SBStream that represents the standard output
dict is an internal utility parameter and should be left untouched
The function should return None on no error, or an error string to describe any problems
llvm-svn: 137722
Add code to test case to create an evil linked list with:
task_evil -> task_2 -> task_3 -> task_evil ...
and to check that the linked list iterator only iterates 3 times.
llvm-svn: 137291
where an empty linked list is represented as a value object with a NULL value, instead of a special value
object which 'points' to NULL.
Also modifies the test case to comply.
rdar://problem/9933692
llvm-svn: 137289
Add the rich comparison methods (__eq__, __ne__) to SBType, too.
o lldbtest.py:
Add debug utility method TestBase.DebugSBType().
o test/python_api/type:
Add tests for exercising SBType/SBTypeList API, including the SBTarget.FindTypes(type_name)
API which returns a SBTypeList matching the type_name.
llvm-svn: 136975