- you can now define a Python class as a synthetic children producer for a type
the class must adhere to this "interface":
def __init__(self, valobj, dict):
def get_child_at_index(self, index):
def get_child_index(self, name):
then using type synth add -l className typeName
(e.g. type synth add -l fooSynthProvider foo)
(This is still WIP with lots to be added)
A small test case is available also as reference
llvm-svn: 135865
(e.g. ${var%S}). this might already be the default if your variable is of an aggregate type
new feature: synthetic filters. you can restrict the number of children for your variables to only a meaningful subset
- the restricted list of children obeys the typical rules (e.g. summaries prevail over children)
- one-line summaries show only the filtered (synthetic) children, if you type an expanded summary string, or you use Python scripts, all the real children are accessible
- to provide a synthetic children list use the "type synth add" command, as in:
type synth add foo_type --child varA --child varB[0] --child varC->packet->flags[1-4]
(you can use ., ->, single-item array operator [N] and bitfield operator [N-M]; array slice access is not supported, giving simplified names to expression paths is not supported)
- a new -S option to frame variable and target variable lets you override synthetic children and instead show real ones
llvm-svn: 135731
Code cleanup:
- The Format Manager implementation is now split between two files: FormatClasses.{h|cpp} where the
actual formatter classes (ValueFormat, SummaryFormat, ...) are implemented and
FormatManager.{h|cpp} where the infrastructure classes (FormatNavigator, FormatManager, ...)
are contained. The wrapper code always remains in Debugger.{h|cpp}
- Several leftover fields, methods and comments from previous design choices have been removed
type category subcommands (enable, disable, delete) now can take a list of category names as input
- for type category enable, saying "enable A B C" is the same as saying
enable C
enable B
enable A
(the ordering is relevant in enabling categories, and it is expected that a user typing
enable A B C wants to look into category A, then into B, then into C and not the other
way round)
- for the other two commands, the order is not really relevant (however, the same inverted ordering
is used for consistency)
llvm-svn: 135494
The "systemwide summaries" feature has been removed and replaced with a more general and
powerful mechanism.
Categories:
- summaries can now be grouped into buckets, called "categories" (it is expected that categories
correspond to libraries and/or runtime environments)
- to add a summary to a category, you can use the -w option to type summary add and give
a category name (e.g. type summary add -f "foo" foo_t -w foo_category)
- categories are by default disabled, which means LLDB will not look into them for summaries,
to enable a category use "type category enable". once a category is enabled, LLDB will
look into that category for summaries. the rules are quite trivial: every enabled category
is searched for an exact match. if an exact match is nowhere to be found, any match is
searched for in every enabled category (whether it involves cascading, going to base classes,
...). categories are searched into the order in which they were enabled (the most recently
enabled category first, then the second most and so on..)
- by default, most commands that deal with summaries, use a category named "default" if no
explicit -w parameter is given (the observable behavior of LLDB should not change when
categories are not explicitly used)
- the systemwide summaries are now part of a "system" category
llvm-svn: 135463
- Summaries for char*, const char* and char[] are loaded at startup as
system-wide summaries. This means you cannot delete them unless you use
the -a option to type summary delete/clear
- You can add your own system-wide summaries by using the -w option to type
summary add
Several code improvements for the Python summaries feature
llvm-svn: 135326
- you can use a Python script to write a summary string for data-types, in one of
three ways:
-P option and typing the script a line at a time
-s option and passing a one-line Python script
-F option and passing the name of a Python function
these options all work for the "type summary add" command
your Python code (if provided through -P or -s) is wrapped in a function
that accepts two parameters: valobj (a ValueObject) and dict (an LLDB
internal dictionary object). if you use -F and give a function name,
you're expected to define the function on your own and with the right
prototype. your function, however defined, must return a Python string
- test case for the Python summary feature
- a few quirks:
Python summaries cannot have names, and cannot use regex as type names
both issues will be fixed ASAP
major redesign of type summary code:
- type summary working with strings and type summary working with Python code
are two classes, with a common base class SummaryFormat
- SummaryFormat classes now are able to actively format objects rather than
just aggregating data
- cleaner code to print descriptions for summaries
the public API now exports a method to easily navigate a ValueObject hierarchy
New InputReaderEZ and PriorityPointerPair classes
Several minor fixes and improvements
llvm-svn: 135238
- formats %s %char[] %c and %a now work to print 0-terminated c-strings if they are applied to a char* or char[] even without the [] operator (e.g. ${var%s})
- array formats (char[], intN[], ..) now work when applied to an array of a scalar type even without the [] operator (e.g. ${var%int32_t[]})
LLDB will not crash because of endless loop when trying to obtain a summary for an object that has no value and references itself in its summary string
In many cases, a wrong summary string will now display an "<error>" message instead of giving out an empty string
llvm-svn: 135007
- a new --name option for "type summary add" lets you give a name to a summary
- a new --summary option for "frame variable" lets you bind a named summary to one or more variables
${var%s} now works for printing the value of 0-terminated CStrings
type format test case now tests for cascading
- this is disabled on GCC because GCC may end up stripping typedef chains, basically breaking cascading
new design for the FormatNavigator class
new template class CleanUp2 meant to support cleanup routines with 1 additional parameter beyond resource handle
llvm-svn: 134943
new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way
changes to the varformats.html document (WIP)
llvm-svn: 134679
instructions if they are conditional. Also fixed issues where the PC wasn't
getting bit zero stripped for ARM targets when a stack frame was thumb. We
now properly call through the GetOpcodeLoadAddress() functions to make sure
the addresses are properly stripped for any targets that may decorate up
their addresses.
We now don't pass the SIGSTOP signals along. We can revisit this soon, but
currently this was interfering with debugging some older ARM targets that
don't have vCont support in the GDB server.
llvm-svn: 134461
- ${*expr} now simply means to dereference expr before actually using it
- bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way
a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies
when one-lining summary strings, children's summaries can be used as well as values
llvm-svn: 134458
- type names can now be regular expressions (exact matching is done first, and is faster)
- integral (and floating) types can be printed as bitfields, i.e. ${var[low-high]} will extract bits low thru high of the value and print them
- array subscripts are supported, both for arrays and for pointers. the syntax is ${*var[low-high]}, or ${*var[]} to print the whole array (the latter only works for statically sized arrays)
- summary is now printed by default when a summary string references a variable. if that variable's type has no summary, value is printed instead. to force value, you can use %V as a format specifier
- basic support for ObjectiveC:
- ObjectiveC inheritance chains are now walked through
- %@ can be specified as a summary format, to print the ObjectiveC runtime description for an object
- some bug fixes
llvm-svn: 134293
implements three commands:
type summary add <format> <typename1> [<typename2> ...]
type summary delete <typename1> [<typename2> ...]
type summary list [<typename1> [<typename2>] ...]
type summary clear
This allows you to specify the default format that will be used to display
summaries for variables, shown when you use "frame variable" or "expression", or the SBValue classes.
Examples:
type summary add "x = ${var.x}" Point
type summary list
type summary add --one-liner SimpleType
llvm-svn: 134108
the FormatManager class. Modified the format arguments in any commands to be
able to use a single character format, or a full format name, or a partial
format name if no full format names match.
Modified any code that was displaying formats to use the new FormatManager
calls so that our help text and errors never get out of date.
Modified the display of the "type format list" command to be a bit more
human readable by showing the format as a format string rather than the single
character format char.
llvm-svn: 133765
This commit adds a new top level command named "type". Currently this command
implements three commands:
type format add <format> <typename1> [<typename2> ...]
type format delete <typename1> [<typename2> ...]
type format list [<typename1> [<typename2>] ...]
This allows you to specify the default format that will be used to display
types when you use "frame variable" or "expression", or the SBValue classes.
Examples:
// Format uint*_t as hex
type format add x uint16_t uint32_t uint64_t
// Format intptr_t as a pointer
type format add p intptr_t
The format characters are the same as "printf" for the most part with many
additions. These format character specifiers are also used in many other
commands ("frame variable" for one). The current list of format characters
include:
a - char buffer
b - binary
B - boolean
c - char
C - printable char
d - signed decimal
e - float
f - float
g - float
i - signed decimal
I - complex integer
o - octal
O - OSType
p - pointer
s - c-string
u - unsigned decimal
x - hex
X - complex float
y - bytes
Y - bytes with ASCII
llvm-svn: 133728
not write output (prompts, instructions,etc.) if the CommandInterpreter
is in batch_mode.
Also, finish updating InputReaders to write to the asynchronous stream,
rather than using the Debugger's output file directly.
llvm-svn: 133162
(or anything running in a terminal) wants. Not what a UI (Xcode) would want
where it creates a debugger per debug window. The current code had an infinite
loop after a debug session ended.
llvm-svn: 132280
the appropriate registers for arm and x86_64. The register names for the
arguments that are the size of a pointer or less are all named "arg1", "arg2",
etc. This allows you to read these registers by name:
(lldb) register read arg1 arg2 arg3
...
You can also now specify you want to see alternate register names when executing
the read register command:
(lldb) register read --alternate
(lldb) register read -A
llvm-svn: 131376
into some cleanup I have been wanting to do when reading/writing registers.
Previously all RegisterContext subclasses would need to implement:
virtual bool
ReadRegisterBytes (uint32_t reg, DataExtractor &data);
virtual bool
WriteRegisterBytes (uint32_t reg, DataExtractor &data, uint32_t data_offset = 0);
There is now a new class specifically designed to hold register values:
lldb_private::RegisterValue
The new register context calls that subclasses must implement are:
virtual bool
ReadRegister (const RegisterInfo *reg_info, RegisterValue ®_value) = 0;
virtual bool
WriteRegister (const RegisterInfo *reg_info, const RegisterValue ®_value) = 0;
The RegisterValue class must be big enough to handle any register value. The
class contains an enumeration for the value type, and then a union for the
data value. Any integer/float values are stored directly in an appropriate
host integer/float. Anything bigger is stored in a byte buffer that has a length
and byte order. The RegisterValue class also knows how to copy register value
bytes into in a buffer with a specified byte order which can be used to write
the register value down into memory, and this does the right thing when not
all bytes from the register values are needed (getting a uint8 from a uint32
register value..).
All RegiterContext and other sources have been switched over to using the new
regiter value class.
llvm-svn: 131096
command line driver, including the lldb prompt being output by
editline, the asynchronous process output & error messages, and
asynchronous messages written by target stop-hooks.
As part of this it introduces a new Stream class,
StreamAsynchronousIO. A StreamAsynchronousIO object is created with a
broadcaster, who will eventually broadcast the stream's data for a
listener to handle, and an event type indicating what type of event
the broadcaster will broadcast. When the Write method is called on a
StreamAsynchronousIO object, the data is appended to an internal
string. When the Flush method is called on a StreamAsynchronousIO
object, it broadcasts it's data string and clears the string.
Anything in lldb-core that needs to generate asynchronous output for
the end-user should use the StreamAsynchronousIO objects.
I have also added a new notification type for InputReaders, to let
them know that a asynchronous output has been written. This is to
allow the input readers to, for example, refresh their prompts and
lines, if desired. I added the case statements to all the input
readers to catch this notification, but I haven't added any code for
handling them yet (except to the IOChannel input reader).
llvm-svn: 130721
set by default when dumping registers. If you want to see all of the register
sets you can use the "--all" option:
(lldb) register read --all
If you want to just see some register sets, you can currently specify them
by index:
(lldb) register read --set 0 --set 2
We need to get shorter register set names soon so we can specify the register
sets by name without having to type too much. I will make this change soon.
You can also have any integer encoded registers resolve the address values
back to any code or data from the object files using the "--lookup" option.
Below is sample output when stopped in the libc function "puts" with some
const strings in registers:
Process 8973 stopped
* thread #1: tid = 0x2c03, 0x00007fff828fa30f libSystem.B.dylib`puts + 1, stop reason = instruction step into
frame #0: 0x00007fff828fa30f libSystem.B.dylib`puts + 1
(lldb) register read --lookup
General Purpose Registers:
rax = 0x0000000100000e98 "----------------------------------------------------------------------"
rbx = 0x0000000000000000
rcx = 0x0000000000000001
rdx = 0x0000000000000000
rdi = 0x0000000100000e98 "----------------------------------------------------------------------"
rsi = 0x0000000100800000
rbp = 0x00007fff5fbff710
rsp = 0x00007fff5fbff280
r8 = 0x0000000000000040
r9 = 0x0000000000000000
r10 = 0x0000000000000000
r11 = 0x0000000000000246
r12 = 0x0000000000000000
r13 = 0x0000000000000000
r14 = 0x0000000000000000
r15 = 0x0000000000000000
rip = 0x00007fff828fa30f libSystem.B.dylib`puts + 1
rflags = 0x0000000000000246
cs = 0x0000000000000027
fs = 0x0000000000000000
gs = 0x0000000000000000
As we can see, we see two constant strings and the PC (register "rip") is
showing the code it resolves to.
I fixed the register "--format" option to work as expected.
Added a setting to disable skipping the function prologue when setting
breakpoints as a target settings variable:
(lldb) settings set target.skip-prologue false
Updated the user settings controller boolean value handler funciton to be able
to take the default value so it can correctly respond to the eVarSetOperationClear
operation.
Did some usability work on the OptionValue classes.
Fixed the "image lookup" command to correctly respond to the "--verbose"
option and display the detailed symbol context information when looking up
line table entries and functions by name. This previously was only working
for address lookups.
llvm-svn: 129977
the CommandInterpreter where it was always being used.
Make sure that Modules can track their object file offsets correctly to
allow opening of sub object files (like the "__commpage" on darwin).
Modified the Platforms to be able to launch processes. The first part of this
move is the platform soon will become the entity that launches your program
and when it does, it uses a new ProcessLaunchInfo class which encapsulates
all process launching settings. This simplifies the internal APIs needed for
launching. I want to slowly phase out process launching from the process
classes, so for now we can still launch just as we used to, but eventually
the platform is the object that should do the launching.
Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able
to launch processes with all of the new eLaunchFlag settings. Modified any
code that was manually launching processes to use the Host::LaunchProcess
functions.
Fixed an issue where lldb_private::Args had implicitly defined copy
constructors that could do the wrong thing. This has now been fixed by adding
an appropriate copy constructor and assignment operator.
Make sure we don't add empty ModuleSP entries to a module list.
Fixed the commpage module creation on MacOSX, but we still need to train
the MacOSX dynamic loader to not get rid of it when it doesn't have an entry
in the all image infos.
Abstracted many more calls from in ProcessGDBRemote down into the
GDBRemoteCommunicationClient subclass to make the classes cleaner and more
efficient.
Fixed the default iOS ARM register context to be correct and also added support
for targets that don't support the qThreadStopInfo packet by selecting the
current thread (only if needed) and then sending a stop reply packet.
Debugserver can now start up with a --unix-socket (-u for short) and can
then bind to port zero and send the port it bound to to a listening process
on the other end. This allows the GDB remote platform to spawn new GDB server
instances (debugserver) to allow platform debugging.
llvm-svn: 129351
public types and public enums. This was done to keep the SWIG stuff from
parsing all sorts of enums and types that weren't needed, and allows us to
abstract our API better.
llvm-svn: 128239
platform status -- gets status information for the selected platform
platform create <platform-name> -- creates a new instance of a remote platform
platform list -- list all available platforms
platform select -- select a platform instance as the current platform (not working yet)
When using "platform create" it will create a remote platform and make it the
selected platform. For instances for iPhone OS debugging on Mac OS X one can
do:
(lldb) platform create remote-ios --sdk-version=4.0
Remote platform: iOS platform
SDK version: 4.0
SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0"
Not connected to a remote device.
(lldb) file ~/Documents/a.out
Current executable set to '~/Documents/a.out' (armv6).
(lldb) image list
[ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out
[ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld
[ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib
Note that this is all happening prior to running _or_ connecting to a remote
platform. Once connected to a remote platform the OS version might change which
means we will need to update our dependecies. Also once we run, we will need
to match up the actualy binaries with the actualy UUID's to files in the
SDK, or download and cache them locally.
This is just the start of the remote platforms, but this modification is the
first iteration in getting the platforms really doing something.
llvm-svn: 127934
correct order. Previously this was tacitly implemented but not
enforced, so it was possible to accidentally do things in the wrong
order and cause problems. This fixes that problem.
llvm-svn: 127430
of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up
doing was:
- Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics
the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple
to give us the machine type from llvm::Triple::ArchType.
- There is a new ArchSpec::Core definition which further qualifies the CPU
core we are dealing with into a single enumeration. If you need support for
a new Core and want to debug it in LLDB, it must be added to this list. In
the future we can allow for dynamic core registration, but for now it is
hard coded.
- The ArchSpec can now be initialized with a llvm::Triple or with a C string
that represents the triple (it can just be an arch still like "i386").
- The ArchSpec can still initialize itself with a architecture type -- mach-o
with cpu type and subtype, or ELF with e_machine + e_flags -- and this will
then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core.
The mach-o cpu type and subtype can be accessed using the getter functions:
uint32_t
ArchSpec::GetMachOCPUType () const;
uint32_t
ArchSpec::GetMachOCPUSubType () const;
But these functions are just converting out internal llvm::Triple::ArchSpec
+ ArchSpec::Core back into mach-o. Same goes for ELF.
All code has been updated to deal with the changes.
This should abstract us until later when the llvm::TargetSpec stuff gets
finalized and we can then adopt it.
llvm-svn: 126278
now, in addition to cpu type/subtype and architecture flavor, contains:
- byte order (big endian, little endian)
- address size in bytes
- llvm::Triple for true target triple support and for more powerful plug-in
selection.
llvm-svn: 125602
where the implementation is hidden in the host layer. This avoids
a slew of "#if LLDB_CONFIG_TERMIOS_SUPPORTED" statements in the
code and keeps things cleaner.
llvm-svn: 125057
#include "lldb/Host/Config.h"
Or the LLDB_CONFIG_TERMIOS_SUPPORTED defined won't be set. I will fix all
of this Termios stuff later today by moving lldb/Core/TTYState.* into the
host layer and then we conditionalize all of this inside TTYState.cpp and
then we get rid of LLDB_CONFIG_TERMIOS_SUPPORTED all together.
Typically, when we start to see too many "#if LLDB_CONFIG_XXXX" preprocessor
directives, this is a good indicator that something needs to be moved over to
the host layer. TTYState can be modified to do all of the things that many
areas of the code are currently doing, and it will avoid all of the
preprocessor noise.
llvm-svn: 125027
allowing timeouts & informing the user when the lock is unavailable.
Fixed problem where Debugger::Terminate was clearing the debugger list
even when the global ref count was greater than zero.
llvm-svn: 123674
exist within the same process (one script interpreter object per debugger object). The
python script interpreter objects are all using the same global Python script interpreter;
they use separate dictionaries to keep their data separate, and mutex's to prevent any object
attempting to use the global Python interpreter when another object is already using it.
llvm-svn: 123415
an issue with the way the UnwindLLDB was handing out RegisterContexts: it
was making shared pointers to register contexts and then handing out just
the pointers (which would get put into shared pointers in the thread and
stack frame classes) and cause double free issues. MallocScribble helped to
find these issues after I did some other cleanup. To help avoid any
RegisterContext issue in the future, all code that deals with them now
returns shared pointers to the register contexts so we don't end up with
multiple deletions. Also now that the RegisterContext class doesn't require
a stack frame, we patched a memory leak where a StackFrame object was being
created and leaked.
Made the RegisterContext class not have a pointer to a StackFrame object as
one register context class can be used for N inlined stack frames so there is
not a 1 - 1 mapping. Updates the ExecutionContextScope part of the
RegisterContext class to never return a stack frame to indicate this when it
is asked to recreate the execution context. Now register contexts point to the
concrete frame using a concrete frame index. Concrete frames are all of the
frames that are actually formed on the stack of a thread. These concrete frames
can be turned into one or more user visible frames due to inlining. Each
inlined stack frame has the exact same register context (shared via shared
pointers) as any parent inlined stack frames all the way up to the concrete
frame itself.
So now the stack frames and the register contexts should behave much better.
llvm-svn: 122976
a Debugger object is destroyed or re-set. (Thus making sure that, for
example, the Python interpreter finishes and exits cleanly rather than
being left in an undefined state.)
llvm-svn: 122255
do. Closing on EOF is an option that can be set on the
lldb_private::Communication or the lldb::SBCommunication objects after they
are created. Of course the EOF support isn't hooked up, so they don't do
anything at the moment, but they are left in so when the code is fixed, it
will be easy to get working again.
llvm-svn: 120885
was done as an settings variable in the process for now. We will eventually
move all environment stuff over to the target, but we will leave it with the
process for now. The default setting is for a process to inherit the host
environment. This can be disabled by setting the "inherit-env" setting to
false in the process.
llvm-svn: 120862
Add bool member to Communication class indicating whether the
Connection should be closed on receiving an EOF or not. Update the
Connection read to return an EOF status when appropriate. Modify the
Communication class to pass the EOF along or not, and to close the
Connection or not, as appropriate.
llvm-svn: 120723
Enrico Granata