- Completely new implementation of SBType
- Various enhancements in several other classes
Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>:
- these return the actual elements into the container as the children of the container
- basic template name parsing that works (hopefully) on both Clang and GCC
- find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth
New summary string token ${svar :
- the syntax is just the same as in ${var but this new token lets you read the values
coming from the synthetic children provider instead of the actual children
- Python providers above provide a synthetic child len that returns the number of elements
into the container
Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB
Several other fixes, including:
- inverted the order of arguments in the ClangASTType constructor
- EvaluationPoint now only returns SharedPointer's to Target and Process
- the help text for several type subcommands now correctly indicates argument-less options as such
llvm-svn: 136504
expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will
have to be changed to also query for the dynamic types & offsets as it is looking up variables.
The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var
command to get the dynamic or static value of the variables you are printing.
There's also a general setting:
target.prefer-dynamic-value (boolean) = 'true'
which is consulted if you call "frame var" without supplying a value for the -d option.
llvm-svn: 129623
an interface to a local or remote debugging platform. By default each host OS
that supports LLDB should be registering a "default" platform that will be
used unless a new platform is selected. Platforms are responsible for things
such as:
- getting process information by name or by processs ID
- finding platform files. This is useful for remote debugging where there is
an SDK with files that might already or need to be cached for debug access.
- getting a list of platform supported architectures in the exact order they
should be selected. This helps the native x86 platform on MacOSX select the
correct x86_64/i386 slice from universal binaries.
- Connect to remote platforms for remote debugging
- Resolving an executable including finding an executable inside platform
specific bundles (macosx uses .app bundles that contain files) and also
selecting the appropriate slice of universal files for a given platform.
So by default there is always a local platform, but remote platforms can be
connected to. I will soon be adding a new "platform" command that will support
the following commands:
(lldb) platform connect --name machine1 macosx connect://host:port
Connected to "machine1" platform.
(lldb) platform disconnect macosx
This allows LLDB to be well setup to do remote debugging and also once
connected process listing and finding for things like:
(lldb) process attach --name x<TAB>
The currently selected platform plug-in can now auto complete any available
processes that start with "x". The responsibilities for the platform plug-in
will soon grow and expand.
llvm-svn: 127286
Enrico Granata