end of list test function as __eol_test__.
The simple example can be reduced to:
for t in task_head.linked_list_iter('next'):
print t
Modify the test program to exercise the API for both cases: supplying or not
supplying an end of list test function.
llvm-svn: 136144
too complex in the test case. We can just simply test that the SBValue object
is a valid object and it does not correspond to a null pointer in order to say
that EOL has not been reached.
Modify the test case and the lldb.py docstring to have a more compact test
function.
llvm-svn: 136123
to iterate through an SBValue instance by treating it as the head of a linked
list. API program must provide two args to the linked_list_iter() method:
the first being the child member name which points to the next item on the list
and the second being a Python function which an SBValue (for the next item) and
returns True if end of list is reached, otherwise it returns False.
For example, suppose we have the following sample program.
#include <stdio.h>
class Task {
public:
int id;
Task *next;
Task(int i, Task *n):
id(i),
next(n)
{}
};
int main (int argc, char const *argv[])
{
Task *task_head = new Task(-1, NULL);
Task *task1 = new Task(1, NULL);
Task *task2 = new Task(2, NULL);
Task *task3 = new Task(3, NULL); // Orphaned.
Task *task4 = new Task(4, NULL);
Task *task5 = new Task(5, NULL);
task_head->next = task1;
task1->next = task2;
task2->next = task4;
task4->next = task5;
int total = 0; // Break at this line
Task *t = task_head;
while (t != NULL) {
if (t->id >= 0)
++total;
t = t->next;
}
printf("We have a total number of %d tasks\n", total);
return 0;
}
The test program produces the following output while exercising the linked_list_iter() SBVAlue API:
task_head:
TypeName -> Task *
ByteSize -> 8
NumChildren -> 2
Value -> 0x0000000106400380
ValueType -> local_variable
Summary -> None
IsPointerType -> True
Location -> 0x00007fff65f06e60
(Task *) next = 0x0000000106400390
(int) id = 1
(Task *) next = 0x00000001064003a0
(Task *) next = 0x00000001064003a0
(int) id = 2
(Task *) next = 0x00000001064003c0
(Task *) next = 0x00000001064003c0
(int) id = 4
(Task *) next = 0x00000001064003d0
(Task *) next = 0x00000001064003d0
(int) id = 5
(Task *) next = 0x0000000000000000
llvm-svn: 135938
added a final newline to fooSynthProvider.py
new option to automatically save user input in InputReaderEZ
checking for NULL pointers in several new places
llvm-svn: 135916
- 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
API.
SBTarget changes include changing:
bool
SBTarget::ResolveLoadAddress (lldb::addr_t vm_addr,
lldb::SBAddress& addr);
to be:
lldb::SBAddress
SBTarget::ResolveLoadAddress (lldb::addr_t vm_addr);
SBAddress can how contruct itself using a load address and a target
which can be used to resolve the address:
SBAddress (lldb::addr_t load_addr, lldb::SBTarget &target);
This will actually just call the new SetLoadAddress accessor:
void
SetLoadAddress (lldb::addr_t load_addr,
lldb::SBTarget &target);
This function will always succeed in making a SBAddress object
that can be used in API calls (even if "target" isn't valid).
If "target" is valid and there are sections currently loaded,
then it will resolve the address to a section offset address if
it can. Else an address with a NULL section and an offset that is
the "load_addr" that was passed in. We do this because a load address
might be from the heap or stack.
llvm-svn: 135770
(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
- help type summary add now gives some hints on how to use it
frame variable and target variable now have a --no-summary-depth (-Y) option:
- simply using -Y without an argument will skip one level of summaries, i.e.
your aggregate types will expand their children and display no summary, even
if they have one. children will behave normally
- using -Y<int>, as in -Y4, -Y7, ..., will skip as many levels of summaries as
given by the <int> parameter (obviously, -Y and -Y1 are the same thing). children
beneath the given depth level will behave normally
-Y0 is the same as omitting the --no-summary-depth parameter entirely
This option replaces the defined-but-unimplemented --no-summary
llvm-svn: 135336
- 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
represent pointers and arrays by adding an extra parameter to the
SBValue
SBValue::GetChildAtIndex (uint32_t idx,
DynamicValueType use_dynamic,
bool can_create_synthetic);
The new "can_create_synthetic" will allow you to create child values that
aren't actually a part of the original type. So if you code like:
int *foo_ptr = ...
And you have a SBValue that contains the value for "foo_ptr":
SBValue foo_value = ...
You can now get the "foo_ptr[12]" item by doing this:
v = foo_value.GetChiltAtIndex (12, lldb.eNoDynamicValues, True);
Normall the "foo_value" would only have one child value (an integer), but
we can create "synthetic" child values by treating the pointer as an array.
Likewise if you have code like:
int array[2];
array_value = ....
v = array_value.GetChiltAtIndex (0); // Success, v will be valid
v = array_value.GetChiltAtIndex (1); // Success, v will be valid
v = array_value.GetChiltAtIndex (2); // Fail, v won't be valid, "2" is not a valid zero based index in "array"
But if you use the ability to create synthetic children:
v = array_value.GetChiltAtIndex (0, lldb.eNoDynamicValues, True); // Success, v will be valid
v = array_value.GetChiltAtIndex (1, lldb.eNoDynamicValues, True); // Success, v will be valid
v = array_value.GetChiltAtIndex (2, lldb.eNoDynamicValues, True); // Success, v will be valid
llvm-svn: 135292
- 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
The reasom of the crash is because of a missing entry in the argument table corresponding to eArgTypeUnsignedInteger.
Add such entry and modify the call site of the crash to go through a fail-fast API to retrieve the argument table.
Add a regression test to TestHelp.py.
llvm-svn: 135206
clang/gcc/llvm-gcc. If the first breakpoint is due to stop at an inlined
frame, test that the call site corresponds to where it should be. Also add
an expecr for a second break stop, if the first break stop corresponds to an
inlined call frame #0.
rdar://problem/9741470
llvm-svn: 135100
- 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
is just wrong and resulted in the inferior's output getting mixed into the GDB remote communication's
log file. Change all test cases to not pass os.ctermid() and either use SBTarget.LaunchSimple() or
SBTarget.Launch() and pass None as stdin_path/stdout_path/srderr_path to use a pseudo terminal.
rdar://problem/9716499 program output is getting mixed into the GDB remote communications
llvm-svn: 134940
before issuing API calls to find the global variable and to get its value.
rdar://problem/9700873 has been updated to reflect the latest status. The dwarf case
now does not seg fault if the inferior is not started; instead, for dwarf case, the
value retrieved from the global variable is None.
llvm-svn: 134909
Add a usage example of SBEvent APIs.
o SBEvent.h and SBListener.h:
Add method docstrings for SBEvent.h and SBListener.h, and example usage of SBEvent into
the class docstring of SBEvent.
o lldb.swig:
Add typemap for SBEvent::SBEvent (uint32_t event, const char *cstr, uint32_t cstr_len)
so that we can use, in Python, obj2 = lldb.SBEvent(0, "abc") to create an SBEvent.
llvm-svn: 134766
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
group class: OptionGroupVariable. It gets initialized with
a boolean that indicates if the frame specific options are
included so that this can be used in both the "frame variable"
and "target variable" commands.
Removed the global functionality from the "frame variable"
command. Users should switch to using the "target variable"
command.
llvm-svn: 134594
would return instead of a less than helpful "name: '%s'" description.
Make sure that when we ask for the error from a ValueObject object we
first update the value if needed.
Cleaned up some SB functions to use internal functions and not re-call
through the public API when possible.
llvm-svn: 134497
- ${*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
"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
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
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
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
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
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
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
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
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
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
those lldb objects which implement the IsValid() method, let's change the rest of
the test suite to use the more compact truth value testing pattern (the Python way).
llvm-svn: 131970
object.__nonzero__(self) is called to implement truth value testing and the built-in operation bool(),
via a simple delegation to self.IsValid().
Change tests under python_api/lldbutil to utilize this mechanism.
llvm-svn: 131494
unambiguous iteration support. So that we could, for example:
...
REGs = lldbutil.get_GPRs(frame)
print "Number of general purpose registers: %d" % len(REGs)
for reg in REGs:
print "%s => %s" %(reg.GetName(), reg.GetValue())
...
llvm-svn: 131418
representing variables whose type must be inferred
from the way they are used. Functions without debug
information now return UnknownAnyTy and must be cast.
Variables with no debug information are not yet using
UnknownAnyTy; instead they are assumed to be void*.
Support for variables of unknown type is coming (and,
in fact, some relevant support functions are included
in this commit) but will take a bit of extra effort.
The testsuite has also been updated to reflect the new
requirement that the result of printf be cast, i.e.
expr (int) printf("Hello world!")
llvm-svn: 131263
o get_parent_frame(frame)
o get_args_as_string(frame)
to lldbutil.py and create TestFrameUtils.py to exercise the utils.
Plus re-arrange the test/python_api/lldbutil to have three directories
for testing iteration, process stack traces, and the just added frame utils.
llvm-svn: 131213
compile unit, which has an external reference to symbols defined in foo.m, the type query:
in this case, 'expression (NSArray*)array_token'
continues to work.
This test is to accompany http://llvm.org/viewvc/llvm-project?rev=131145&view=rev.
llvm-svn: 131154
Also add three convenience functions get_GPRs(frame), get_FPRs(frame), and get_ESRs(frame) to get the general
purpose registers, the floating point registers, and the exception state registers.
Add TestRegistersIterator.py to test these added functions of lldbutil.py.
llvm-svn: 131144
Change one test sequence to detect the '** End Stop Hooks **' marker emitted by the
stop hooks mechanism and check for whether the 'expr ptr' stop-hook has been run.
Also, change the TestBase.tearDown() to wait for 2 seocnds before forcefully kill
the pexpect-spawned child lldb process.
llvm-svn: 130767
to spawn an lldb child command. The test is not "correct" in that the '** Stop Hooks **'
message emitted by the Target implementation is invoked asynchronously and is using a separate:
CommandReturnObject result;
command return object that what the driver passes to the normal command interpreter loop.
But it can help test our output serialization work.
I need to modify the test case later to maybe only test that "-o 'expr ptr'" option does indeed work.
llvm-svn: 130742
the breakpoint ID and provides the semantics needed for '==' and '!='. And
modify LLDBIteratorTestCase.lldb_iter_2() to use '==' between two SBBreakpoint's.
llvm-svn: 130531
This is so that the objects which support the iteration protocol are immediately obvious
from looking at the lldb.py file.
SBTarget supports two types of iterations: module and breakpoint. For an SBTarget instance,
you will need to issue either:
for m in target.module_iter()
or
for b in target.breakpoint_iter()
For other single iteration protocol objects, just use, for example:
for thread in process:
ID = thread.GetThreadID()
for frame in thread:
frame.Disassemble()
....
llvm-svn: 130442
method names of all the lldb container objects and returns an iterator object when
passed an eligible lldb container object.
Example:
from lldb_util import smart_iter
for thread in smart_iter(process):
ID = thread.GetThreadID()
if thread.GetStopReason() == lldb.eStopReasonBreakpoint:
stopped_due_to_breakpoint = True
for frame in smart_iter(thread):
self.assertTrue(frame.GetThread().GetThreadID() == ID)
...
Add a test case for lldb.smart_iter().
llvm-svn: 130332
i.e., with 'SBStream &description' first, followed by 'DescriptionLevel level'.
Modify lldbutil.py so that get_description() for a target or breakpoint location
can just take the lldb object itself without specifying an option to mean option
lldb.eDescriptionLevelBrief. Modify TestTargetAPI.py to exercise this logic path.
llvm-svn: 130147
pointer to a ValueObject or any of its dependent ValueObjects, and the whole cluster will
stay around as long as that shared pointer stays around.
llvm-svn: 130035
before issuing the 'process connect ...' command.
test_comand_regex(): assign the spawned child to self.child so it gets automatically
shutdown during TestBase.tearDown(self).
llvm-svn: 130015
rather than calling "process kill" explicitly at the end of the test.
The test might not even reach the end because it could have failed prematurely.
llvm-svn: 129963
and TestAliases.py. Pass the keyword argument 'check=False' to:
self.runCmd("script my.date()", check=False)
since we want to restore sys.stdout no matter what the outcome of the runCmd is.
llvm-svn: 129949
Johnny Chen