Especially SBProcess.ReadMemory() and SBProcess.WriteMemory() because the generated autodoc strings
make no sense for Python programmers due to typemap (see lldb.swig).
llvm-svn: 134301
- 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
A few of the auto-generated method docstrings don't look right, and may need to be fixed
by either overwriting the auto-gened docstrings or some post-processing steps.
llvm-svn: 134246
"struct ", "class ", and "union " from the start of any type names that are
extracted from clang QualType objects. I had to fix test suite cases that
were expecting the struct/union/class prefix to be there.
llvm-svn: 134132
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
level in the public API.
Also modified the ValueObject values to be able to display global variables
without having a valid running process. The globals will read themselves from
the object file section data if there is no process, and from the process if
there is one.
Also fixed an issue where modifications for dynamic types could cause child
values of ValueObjects to not show up if the value was unable to evaluate
itself (children of NULL pointer objects).
llvm-svn: 134102
Fixed crashes for SBValue fuzz calls.
And change 'bool SBType::IsPointerType(void)' to
'bool SBType::IsAPointerType(void)' to avoid name collision with the static 'bool SBType::IsPointerType(void *)'
function, which SWIG cannot handle.
llvm-svn: 134096
changes that caused all SBValue objects to completely ignore the target
lock due to bad C++ scoping of the target Mutex::Locker variables.
llvm-svn: 134081
two:
eOptionMarkPCSourceLine = (1u << 2), // Mark the source line that contains the current PC (mixed mode only)
eOptionMarkPCAddress = (1u << 3) // Mark the disassembly line the contains the PC
This allows mixed mode to show the line that contains the current PC, and it
allows us to mark the PC address in the disassembly if desired. Having these
be separate gives more control on the disassembly output. SBFrame::Disassemble()
doesn't enable any of these options.
llvm-svn: 134019
Test "print object" where another thread blocks the print object from making progress.
Set a breakpoint on the line in my_pthread_routine. Then switch threads
to the main thread, and do print the lock_me object. Since that will
try to get the lock already gotten by my_pthread_routime thread, it will
have to switch to running all threads, and that should then succeed.
llvm-svn: 133933
arguments in hex-encoded form instead of the old QEnvironment packet
which takes them as plain-text strings. Environment variables
containing remote protocol special chars like '#' would fail to set
with QEnvironment.
llvm-svn: 133857
inspection of namespaces in the expression parser.
ClangExpressionDeclMap hitherto reported that namespaces had
been completely imported, even though the namespaces are
returned empty. To deal with this situation, ClangASTSource
was recently extended with an API to complete incomplete type
definitions, and, for greater efficiency, to complete these
definitions partially, returning only those objects that have
a given name.
This commit supports these APIs on LLDB's side, and uses it
to provide information on types resident in namespaces.
Namespaces are now imported as they were -- that is to say,
empty -- but with minimal import mode on. This means that
Clang will come back and request their contents by name as
needed. We now respond with information on the contained
types; this will be followed soon by information on functions
and variables.
llvm-svn: 133852
connected process connection.
Also added support for more kinds of continue packet when multiple threads
need to continue where some want to continue with signals.
llvm-svn: 133785
Assign the test method name to self.testMethodName. This can be useful for the
test directory (see test/types for a good example) which houses a bunch of executables
compiled from different source files. The default build action is to create a.out as
the binary executable, which can confuse the module cacheing mechanism and result in
the debugger getting a stale image as the target to be debugged, and chaos ensues.
o AbstractBase.py, TestThreadAPI.py:
Use self.testMethodName to our advantage.
o TestLoadUnload.py:
Add expected failure marker to test case test_modules_search_paths().
llvm-svn: 133768
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
Added a fix for where you might have already displayed something with a given
type, then did a "type format add ...", then you display the type again. This
patch will figure out that the format changed and allow us to display the
type with the correct new format.
llvm-svn: 133743
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
- Respect DESTDIR.
- Use the realpath function on the path before prepending DESTDIR.
- Don't depend on liblldb.{so,dylib} being installed already.
- Don't put the DESTDIR into the _lldb.so symlink.
Patch by Elias Pipping!
llvm-svn: 133689
SWIG on Darwin does not support -MT, and it only means that we lose
the .d target, which doesn't seem to be used or needed.
Pointed out by Charles Davis.
llvm-svn: 133660
employ different executable names when creating the target for lldb to debug.
Comparing the log files for the same test case with success/failure results show
that the failed one was setting the breakpoint on some different address than the
succeeded one, leading us to suspect that the file system maybe think it knows better
and caches the wrong executable file (they were all named 'a.out' before) which lldb
subsequently reads from.
Now './dotest.py -v types' passes without specifying the '-w' option.
rdar://problem/9644488
rdar://problem/9649573
llvm-svn: 133649
with no delay between successive test cases. This one happend to capture a test failure where
the inferior shoud stop at a breakpoint but did not (radar will be filed to capture the log files
as well as the test session files):
[12:40:37] johnny:/Volumes/data/lldb/svn/trunk/test $ DEBUG_LLDB_LOG=/tmp/lldb.log DEBUG_GDB_REMOTE_LOG=/tmp/gdb-remote.log ./dotest.py -v -p TestFailures.py
LLDB-63
Path: /Volumes/data/lldb/svn/trunk
URL: https://johnny@llvm.org/svn/llvm-project/lldb/trunk
Repository Root: https://johnny@llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 133529
Node Kind: directory
Schedule: normal
Last Changed Author: jmolenda
Last Changed Rev: 133500
Last Changed Date: 2011-06-20 19:57:15 -0700 (Mon, 20 Jun 2011)
Session logs for test failures/errors/unexpected successes will go into directory '2011-06-21-12_40_42'
Command invoked: python ./dotest.py -v -p TestFailures.py
----------------------------------------------------------------------
Collected 10 tests
1: test_char_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that char-type variables are displayed correctly. ... ok
2: test_char_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that char-type variables are displayed correctly. ... ok
3: test_int_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that int-type variables are displayed correctly. ... ok
4: test_int_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that int-type variables are displayed correctly. ... ok
5: test_long_long_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that 'long long'-type variables are displayed correctly. ... FAIL
6: test_long_long_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that 'long long'-type variables are displayed correctly. ... ok
7: test_long_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that long-type variables are displayed correctly. ... TestFailures.DebugIntegerTypesFailures.test_long_type_with_dsym
FAIL
8: test_long_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that long-type variables are displayed correctly. ... FAIL
9: test_short_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that short-type variables are displayed correctly. ... ok
10: test_short_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that short-type variables are displayed correctly. ... ok
======================================================================
FAIL: test_long_long_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that 'long long'-type variables are displayed correctly.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 102, in test_long_long_type_with_dsym
self.long_long_type()
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 129, in long_long_type
self.generic_type_tester(set(['long long']))
File "/Volumes/data/lldb/svn/trunk/test/types/AbstractBase.py", line 67, in generic_type_tester
"stop reason = breakpoint"])
File "/Volumes/data/lldb/svn/trunk/test/lldbtest.py", line 863, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : Process should be stopped due to breakpoint
======================================================================
FAIL: test_long_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that long-type variables are displayed correctly.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 87, in test_long_type_with_dsym
self.long_type()
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 125, in long_type
self.generic_type_tester(set(['long']))
File "/Volumes/data/lldb/svn/trunk/test/types/AbstractBase.py", line 67, in generic_type_tester
"stop reason = breakpoint"])
File "/Volumes/data/lldb/svn/trunk/test/lldbtest.py", line 863, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : Process should be stopped due to breakpoint
======================================================================
FAIL: test_long_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that long-type variables are displayed correctly.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 94, in test_long_type_with_dwarf
self.long_type()
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 125, in long_type
self.generic_type_tester(set(['long']))
File "/Volumes/data/lldb/svn/trunk/test/types/AbstractBase.py", line 67, in generic_type_tester
"stop reason = breakpoint"])
File "/Volumes/data/lldb/svn/trunk/test/lldbtest.py", line 863, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : Process should be stopped due to breakpoint
----------------------------------------------------------------------
Ran 10 tests in 5.617s
FAILED (failures=3)
Session logs for test failures/errors/unexpected successes can be found in directory '2011-06-21-12_40_42'
[12:40:47] johnny:/Volumes/data/lldb/svn/trunk/test $
llvm-svn: 133537
while back. By default its output will be less verbose than the
old examine-threads.c but adding the '-v' command line flag will
give all the information that examine-threads.c provided plus some.
Of note, this implementation can take a process name -- and it will
use the libproc API so it can match program names longer than 16
characters.
llvm-svn: 133500
if not already specified by the test driver (via ./dotest -w). Remove the AbstractBase.setUp()
method definition when/if we find out the cause of the failures if no delays are inserted
between these test cases.
llvm-svn: 133495
We still have the the issue where running:
./dotest.py -v types
we have test failures where the inferior either runs to exited with status 0 or
the inferior stops but not because of breakpoint (for example):
runCmd: process status
output: Process 90060 stopped
* thread #1: tid = 0x2d03, 0x000000010000e2ca, stop reason = EXC_BAD_ACCESS (code=2, address=0x10000e2ca)
frame #0: 0x000000010000e2ca
There are two cases where the inferior stops for the breakpoint (good), but the expression parser
prints out the wrong information. The two failures are:
Failure-TestFloatTypesExpr.FloatTypesExprTestCase.test_double_type_with_dsym.log
Failure-TestFloatTypesExpr.FloatTypesExprTestCase.test_double_type_with_dwarf.log
I'll file a radar on the two expression parser misbehave, while continue investigating why the
inferior stops for the wrong reason or does not stop at all.
For now, you'll need to do:
./dotest.py -v -w types
llvm-svn: 133488
after initial construction.
There are two exceptions to the above general rules, though; the API objects are
SBCommadnReturnObject and SBStream.
llvm-svn: 133475
level is not eDescriptionLevelBrief. It broke test/TestAliases.py. Besides, to have a brief breakpoint list,
you can do "breakpoint list -b".
llvm-svn: 133455
operator counts due to bad debug DWARF debug info. We now verify the operator
has a valid number of params using the clang operator tables.
llvm-svn: 133375
const char *
SBFrame::GetFunctionName();
bool
SBFrame::IsInlined();
The first one will return the correct name for a frame. The name of a frame is:
- the name of the inlined function (if there is one)
- the name of the concrete function (if there is one)
- the name of the symbol (if there is one)
- NULL
We also can now easily check if a frame is an inline function or not.
llvm-svn: 133357
This us useful because sometomes you have to show a single character as: 'a'
(using eFormatChar) and other times you might have an array of single
charcters for display as: 'a' 'b' 'c', and other times you might want to
show the contents of buffer of characters that can contain non printable
chars: "\0\x22\n123".
This also fixes an issue that currently happens when you have a single character
C string (const char *a = "a"; or char b[1] = { 'b' };) that was being output
as "'a'" incorrectly due to the way the eFormatChar format output worked.
llvm-svn: 133316
issue in the way block variables are marked as parsed. In the DWARF parser we
always parse all blocks for a function at once, so we can mark all blocks as
having all variables parsed and avoid recursive function calls to try and
reparse things that have already been handled.
Fixed an issue with how variables get scoped into blocks. The DWARF parser can
now handle abtract class definitions that contain concrete static variables.
When the concrete instance of the class functions get instantiated, they will
track down the concrete block for the abtract block and add the variable to
each block.
llvm-svn: 133302
Among them are test cases to exercise SBTarget.AttachToProcessWithName(); we attach to "hello_world",
and verify that, after attachment, the currently selected target indeed matches "hello_world".
llvm-svn: 133279
libraries and headers exist. This can be specified using the platform select
function:
platform select --sysroot /Volumes/remote-root remote-macosx
Each platform subclass is free to interpret the sysroot as needed.
Expose the new SDK root directory through the SBDebugger class.
Fixed an issue with the GDB remote protocol where unimplemented packets were
not being handled correctly.
llvm-svn: 133231
darwin (not sure about other platforms).
Modified the communication and connection classes to not require the
BytesAvailable function. Now the "Read(...)" function has a timeout in
microseconds.
Fixed a lot of assertions that were firing off in certain cases and replaced
them with error output and code that can deal with the assertion case.
llvm-svn: 133224
Add a test case for the SBTarget::AttachToProcessWithID() API call.
o main.c:
The change goes with the added test case test_with_dwarf_and_attach_to_process_with_id_api() above.
o SBTarget.cpp:
Checks whether we're in synchronous mode. If yes, let's wait for the process to stop right after attaching.
llvm-svn: 133223
For the print_stacktrace(thread, string_buffer = False) function, if we have debug info
for a frame function, let's also emit the args for the current function.
o TestFrameUtils.py:
Add stronger assertTrue for frame0's args.
o TestPrintStackTraces.py:
Launch the inferior with ["abc", "xyz"] and expect '(int)argc=3' in the stack traces, since
by design the inferior is built with debug info.
llvm-svn: 133204
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
remove the self.runStarted attribute since the automatic shutdown of processes associated
with the targets are now performed automatically.
llvm-svn: 133092
bool SBDebugger::DeleteTarget(lldb::SBTarget &target);
which is used in the test tearDown() phase to cleanup the debugger's target list
so that it won't grow larger and larger as test cases are executed. This is also
a good opportunity to get rid of the arcane requirement that test cases exercising
the Python API must assign the process object to self.process so that it gets
shutdown gracefully. Instead, the shutdown of the process associated with each
target is now being now automatically.
Also get rid of an API from SBTarget class:
SBTarget::DeleteTargetFromList(lldb_private::TargetList *list);
llvm-svn: 133091
like the doc's say it should. Make sure we have a condition before we set up a test whether
we have one, so we only present a "could not parse condition" error if we actually have a condition.
llvm-svn: 133088
Previously the IsValid pattern matched only function signatures of
the form:
def IsValid(*args): ...
However under SWIG 1.3.40 on Linux the signature reads:
def IsValid(self): ...
The new pattern matches both signature types by matching only up to
the left paren.
llvm-svn: 132968
embedded_interpreter.py file rather than keeping it
all in a string and compiling the string (easier to maintain,
easier to read, remove redundancy).
llvm-svn: 132935
to have the value for the map be a "const char *" instead of an unused uint32_t.
This allows us to store the uniqued mangled/demangled counterpart in this map
for mangled names. This also speeds up the mangled/demangled counterpart lookup
that used to be maintained in a STL map by having direct access to the data.
If we eventually need to associate other strings to strings to more data, we
can make the value of the StringMap have a more complex value.
Added the start of a history source and history event class. It isn't being
used by anything yet, but might be shortly.
llvm-svn: 132813
If two SBAddress's have the same module and file address, they are considered equal.
Add a test snippet 'sa1 == sa2' to exercise the rich comparison methods for SBAddress.
llvm-svn: 132807
- The Swig post-processing scripts are now run.
- edit-swig-python-wrapper-file.py has been modified so it can be run
from the Makefile.
- The issue that prompted me to pass -classic to swig is fixed by this,
so -classic isn't passed anymore.
Python shouldn't complain anymore about a missing method 'FindDebuggerByID'
on the SBDebugger object whenever lldb is run.
llvm-svn: 132383
they don't update correctly. Currently if a variable is unavailable due to
a register not being available in a higher frame or due to the PC value
not being a valid location list value, "<unknown type>" will get displayed
as the variable type. I am not sure what other things will fail, so I am
disabling it for now just by letting the default enumeration value default
to it being disabled.
llvm-svn: 132303
(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
virtual bool
ABI::StackUsesFrames () = 0;
Should return true if your ABI uses frames when doing stack backtraces. This
means a frame pointer is used that points to the previous stack frame in some
way or another.
virtual bool
ABI::CallFrameAddressIsValid (lldb::addr_t cfa) = 0;
Should take a look at a call frame address (CFA) which is just the stack
pointer value upon entry to a function. ABIs usually impose alignment
restrictions (4, 8 or 16 byte aligned), and zero is usually not allowed.
This function should return true if "cfa" is valid call frame address for
the ABI, and false otherwise. This is used by the generic stack frame unwinding
code to help determine when a stack ends.
virtual bool
ABI::CodeAddressIsValid (lldb::addr_t pc) = 0;
Validates a possible PC value and returns true if an opcode can be at "pc".
Some ABIs or architectures have fixed width instructions and must be aligned
to a 2 or 4 byte boundary. "pc" can be an opcode or a callable address which
means the load address might be decorated with extra bits (such as bit zero
to indicate a thumb function call for ARM targets), so take this into account
when returning true or false. The address should also be validated to ensure
it is a valid address for the address size of the inferior process. 32 bit
targets should make sure the address is less than UINT32_MAX.
Modified UnwindLLDB to use the new ABI functions to help it properly terminate
stacks.
Modified the mach-o function that extracts dependent files to not resolve the
path as the paths inside a binary might not match those on the current
host system.
llvm-svn: 132021
method definition before other method definitions. Instead, do without it and process
the class with IsValid() method definition in all possible states.
llvm-svn: 132016
Peter Collingbourne