- 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
self.expect("expression -- '(anonymous namespace)::i'", VARIABLES_DISPLAYED_CORRECTLY,
substrs = [" = 3"])
to get rid of the '(anonymous namespace)', which is not c++ syntax, thingy fed to the expression parser.
According to rdar://problem/8668674. It is still marked expectedFailure since the bug has not been fixed.
llvm-svn: 136290
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
The idea is that the instruction to be emulated is actually executed
on the hardware to be emulated, with the before and after state of the
hardware being captured and 'freeze-dried' into .dat files. The
emulation testing code then loads the before & after state from the
.dat file, emulates the instruction using the before state, and
compares the resulting state to the 'after' state. If they match, the
emulation is accurate, otherwise there is a problem.
The final format of the .dat files needs a bit more work; the plan is
to generalize them a bit and to convert the plain values to key-value pairs.
But I wanted to get this first pass committed.
This commit adds arm instruction emulation testing to the testsuite, along with
many initial .dat files.
It also fixes a bug in the llvm disassembler, where 32-bit thumb opcodes
were getting their upper & lower 16-bits reversed.
There is a new Instruction sub-class, that is intended to be loaded
from a .dat file rather than read from an executable. There is also a
new EmulationStateARM class, for handling the before & after states.
EmulationStates for other architetures can be added later when we
emulate their instructions.
llvm-svn: 129832
places that were dumping values for the settings. Centralized all of the
value dumping into a single place. When dumping values that aren't strings
we no longer surround the value with single quotes. When dumping values that
are strings, surround the string value with double quotes. When dumping array
values, assume they are always string values, and don't put quotes around
dictionary values.
llvm-svn: 129826
currently in trace mode (-t to dotest.py), i.e., tracing the lldb command execution.
Change TestInferiorCrashing.inferior_crashing_python(self) to check this flag in
order to print the stack trace of the inferior thread.
llvm-svn: 129785
threads, and stack frame down in the lldb_private::Process,
lldb_private::Thread, lldb_private::StackFrameList and the
lldb_private::StackFrame classes. We had some command line
commands that had duplicate versions of the process status
output ("thread list" and "process status" for example).
Removed the "file" command and placed it where it should
have been: "target create". Made an alias for "file" to
"target create" so we stay compatible with GDB commands.
We can now have multple usable targets in lldb at the
same time. This is nice for comparing two runs of a program
or debugging more than one binary at the same time. The
new command is "target select <target-idx>" and also to see
a list of the current targets you can use the new "target list"
command. The flow in a debug session can be:
(lldb) target create /path/to/exe/a.out
(lldb) breakpoint set --name main
(lldb) run
... hit breakpoint
(lldb) target create /bin/ls
(lldb) run /tmp
Process 36001 exited with status = 0 (0x00000000)
(lldb) target list
Current targets:
target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped )
* target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited )
(lldb) target select 0
Current targets:
* target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped )
target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited )
(lldb) bt
* thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1
frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16
frame #1: 0x0000000100000b64 a.out`start + 52
Above we created a target for "a.out" and ran and hit a
breakpoint at "main". Then we created a new target for /bin/ls
and ran it. Then we listed the targest and selected our original
"a.out" program, so we showed two concurent debug sessions
going on at the same time.
llvm-svn: 129695
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
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
lldb::SymbolType SBSymbol::GetType();
lldb::SectionType SBAddress::GetSectionType ();
lldb::SBModule SBAddress::GetModule ();
Also add an lldb::SBModule::GetUUIDString() API which is easier for Python
to work with in the test script.
llvm-svn: 128695
an architecture into ArchSpec:
uint32_t
ArchSpec::GetMinimumOpcodeByteSize() const;
uint32_t
ArchSpec::GetMaximumOpcodeByteSize() const;
Added an AddressClass to the Instruction class in Disassembler.h.
This allows decoded instructions to know know if they are code,
code with alternate ISA (thumb), or even data which can be mixed
into code. The instruction does have an address, but it is a good
idea to cache this value so we don't have to look it up more than
once.
Fixed an issue in Opcode::SetOpcodeBytes() where the length wasn't
getting set.
Changed:
bool
SymbolContextList::AppendIfUnique (const SymbolContext& sc);
To:
bool
SymbolContextList::AppendIfUnique (const SymbolContext& sc,
bool merge_symbol_into_function);
This function was typically being used when looking up functions
and symbols. Now if you lookup a function, then find the symbol,
they can be merged into the same symbol context and not cause
multiple symbol contexts to appear in a symbol context list that
describes the same function.
Fixed the SymbolContext not equal operator which was causing mixed
mode disassembly to not work ("disassembler --mixed --name main").
Modified the disassembler classes to know about the fact we know,
for a given architecture, what the min and max opcode byte sizes
are. The InstructionList class was modified to return the max
opcode byte size for all of the instructions in its list.
These two fixes means when disassemble a list of instructions and dump
them and show the opcode bytes, we can format the output more
intelligently when showing opcode bytes. This affects any architectures
that have varying opcode byte sizes (x86_64 and i386). Knowing the max
opcode byte size also helps us to be able to disassemble N instructions
without having to re-read data if we didn't read enough bytes.
Added the ability to set the architecture for the disassemble command.
This means you can easily cross disassemble data for any supported
architecture. I also added the ability to specify "thumb" as an
architecture so that we can force disassembly into thumb mode when
needed. In GDB this was done using a hack of specifying an odd
address when disassembling. I don't want to repeat this hack in LLDB,
so the auto detection between ARM and thumb is failing, just specify
thumb when disassembling:
(lldb) disassemble --arch thumb --name main
You can also have data in say an x86_64 file executable and disassemble
data as any other supported architecture:
% lldb a.out
Current executable set to 'a.out' (x86_64).
(lldb) b main
(lldb) run
(lldb) disassemble --arch thumb --count 2 --start-address 0x0000000100001080 --bytes
0x100001080: 0xb580 push {r7, lr}
0x100001082: 0xaf00 add r7, sp, #0
Fixed Target::ReadMemory(...) to be able to deal with Address argument object
that isn't section offset. When an address object was supplied that was
out on the heap or stack, target read memory would fail. Disassembly uses
Target::ReadMemory(...), and the example above where we disassembler thumb
opcodes in an x86 binary was failing do to this bug.
llvm-svn: 128347
rdar://problem/9173060 lldb hangs while running unique-types
disappears if running with clang version >= 3. Modify the TestUniqueTypes.py
to detect if we are running with clang version < 3 and, if true, skip the test.
Update the lldbtest.system() function to return a tuple of (stdoutdata, stderrdata)
since we need the stderr data from "clang -v" command. Modify existing clients of
lldbtest.system() to now use, for example:
# First, capture the golden output emitted by the oracle, i.e., the
# series of printf statements.
- go = system("./a.out", sender=self)
+ go = system("./a.out", sender=self)[0]
# This golden list contains a list of (variable, value) pairs extracted
# from the golden output.
gl = []
And add two utility functions to lldbutil.py.
llvm-svn: 128162
overlap in the SWIG integration which has now been fixed by introducing
callbacks for initializing SWIG for each language (python only right now).
There was also a breakpoint command callback that called into SWIG which has
been abtracted into a callback to avoid cross over as well.
Added a new binary: lldb-platform
This will be the start of the remote platform that will use as much of the
Host functionality to do its job so it should just work on all platforms.
It is pretty hollowed out for now, but soon it will implement a platform
using the GDB remote packets as the transport.
llvm-svn: 128053
types that have different contents. Currently LLDB is incorrectly uniquing,
on MacOSX, the std::vector _VectorImpl class from the two different vector
templates. The DWARF looks like:
0x0000008e: DW_TAG_structure_type [7] *
DW_AT_name( "_Vector_base<int,std::allocator<int> >" )
DW_AT_declaration( 0x01 )
DW_AT_sibling( {0x00000103} )
0x00000098: DW_TAG_structure_type [8] *
DW_AT_name( "_Vector_impl" )
DW_AT_byte_size( 0x18 )
DW_AT_decl_file( "/usr/include/c++/4.2.1/bits/stl_vector.h" )
DW_AT_decl_line( 83 )
0x000000a0: DW_TAG_inheritance [9]
DW_AT_type( {0x000006fa} ( allocator<int> ) )
DW_AT_data_member_location( +0 )
DW_AT_accessibility( DW_ACCESS_public )
0x0000011b: DW_TAG_structure_type [7] *
DW_AT_name( "_Vector_base<short int,std::allocator<short int> >" )
DW_AT_declaration( 0x01 )
DW_AT_sibling( {0x00000190} )
0x00000125: DW_TAG_structure_type [8] *
DW_AT_name( "_Vector_impl" )
DW_AT_byte_size( 0x18 )
DW_AT_decl_file( "/usr/include/c++/4.2.1/bits/stl_vector.h" )
DW_AT_decl_line( 83 )
0x0000012d: DW_TAG_inheritance [9]
DW_AT_type( {0x00000f75} ( allocator<short int> ) )
DW_AT_data_member_location( +0 )
DW_AT_accessibility( DW_ACCESS_public )
In this case it using DIE 0x00000098 for both 0x00000098 and 0x00000125.
This test will help detect this issue once I have a fix for it. I have a fix
that I am testing.
llvm-svn: 127660
This uses pexpect module to spawn a 'lldb' program and uses pseudo-TTY to talk to
the child application.
The test cases test setting breakpoints, adding a stop-hook with line range, and
verifies that when the inferior stops, the stop-hook will fire off when it is
within range and will not fire off when it is out of range.
llvm-svn: 127519
SBTarget.Launch() API, stop at a breakpoint, get the stopped thread, and verify that the
pid of the stopped thread's process is equal to the pid of the process returned by
SBTarget.Launch().
llvm-svn: 127444
Currently it has only test cases for SBThread.GetStopDescription() API.
Also modified lldb.swig to add typemap for (char *dst, size_t dst_len)
which occurs for SBThread::GetStopDescription() C++ API. For Python
scripting:
# Due to the typemap magic (see lldb.swig), we pass in an (int)length to GetStopDescription
# and expect to get a Python string as the result object!
# The 100 is just an arbitrary number specifying the buffer size.
stop_description = thread.GetStopDescription(100)
llvm-svn: 127173
API with a process not in eStateConnected, and checks that the remote launch failed.
Modify SBProcess::RemoteLaunch()/RemoteAttachToProcessWithID()'s log statements to fix a
crasher when logging is turned on.
llvm-svn: 127055
We start a fake debugserver listening on localhost:12345 and issue the command
'process connect connect://localhost:12345' to connect to it.
llvm-svn: 127048
This allows us to override CFLAGS on the command line:
$ CFLAGS='-arch $(ARCH) -gdwarf-2 -O0' ./dotest.py -C clang -A i386 -v objc-optimized
Session logs for test failures/errors will go into directory '2011-03-04-10_33_57'
Command invoked: python ./dotest.py -C clang -A i386 -v objc-optimized
----------------------------------------------------------------------
Collected 2 tests
1: test_break_with_dsym (TestObjcOptimized.ObjcOptimizedTestCase)
Test 'expr member' continues to work for optimized build. ... ok
2: test_break_with_dwarf (TestObjcOptimized.ObjcOptimizedTestCase)
Test 'expr member' continues to work for optimized build. ... ok
----------------------------------------------------------------------
Ran 2 tests in 1.902s
OK
$
llvm-svn: 127011
test that objective-c expression parser continues to work for optimized build.
Radar filed:
# rdar://problem/9087739
# test failure: objc_optimized does not work for "-C clang -A i386"
llvm-svn: 127009
on the command line. For example, use '-A x86_64^i386' to launch the inferior use both x86_64
and i386.
This is an example of building the debuggee using both clang and gcc compiers:
[17:30:46] johnny:/Volumes/data/lldb/svn/trunk/test $ ./dotest.py -C clang^gcc -v -f SourceManagerTestCase.test_modify_source_file_while_debugging
Session logs for test failures/errors will go into directory '2011-03-03-17_31_39'
Command invoked: python ./dotest.py -C clang^gcc -v -f SourceManagerTestCase.test_modify_source_file_while_debugging
Configuration: compiler=clang
----------------------------------------------------------------------
Collected 1 test
1: test_modify_source_file_while_debugging (TestSourceManager.SourceManagerTestCase)
Modify a source file while debugging the executable. ... Command 'run' failed!
original content: #include <stdio.h>
int main(int argc, char const *argv[]) {
printf("Hello world.\n"); // Set break point at this line.
return 0;
}
new content: #include <stdio.h>
int main(int argc, char const *argv[]) {
printf("Hello lldb.\n"); // Set break point at this line.
return 0;
}
os.path.getmtime() after writing new content: 1299202305.0
content restored to: #include <stdio.h>
int main(int argc, char const *argv[]) {
printf("Hello world.\n"); // Set break point at this line.
return 0;
}
os.path.getmtime() after restore: 1299202307.0
ok
----------------------------------------------------------------------
Ran 1 test in 8.259s
OK
Configuration: compiler=gcc
----------------------------------------------------------------------
Collected 1 test
1: test_modify_source_file_while_debugging (TestSourceManager.SourceManagerTestCase)
Modify a source file while debugging the executable. ... original content: #include <stdio.h>
int main(int argc, char const *argv[]) {
printf("Hello world.\n"); // Set break point at this line.
return 0;
}
new content: #include <stdio.h>
int main(int argc, char const *argv[]) {
printf("Hello lldb.\n"); // Set break point at this line.
return 0;
}
os.path.getmtime() after writing new content: 1299202307.0
content restored to: #include <stdio.h>
int main(int argc, char const *argv[]) {
printf("Hello world.\n"); // Set break point at this line.
return 0;
}
os.path.getmtime() after restore: 1299202309.0
ok
----------------------------------------------------------------------
Ran 1 test in 2.301s
OK
[17:31:49] johnny:/Volumes/data/lldb/svn/trunk/test $
llvm-svn: 126979
among other things:
// When stopped on breakppint 1, we can get the line entry using SBFrame API
// SBFrame.GetLineEntry(). We'll get the start address for the the line entry
// with the SBAddress type, resolve the symbol context using the SBTarget API
// SBTarget.ResolveSymbolContextForAddress() in order to get the SBSymbol.
//
// We then stop at breakpoint 2, get the SBFrame, and the the SBFunction object.
//
// The address from calling GetStartAddress() on the symbol and the function
// should point to the same address, and we also verify that.
And add one utility function disassemble(target, function_or_symbol) to lldbutil.py:
"""Disassemble the function or symbol given a target.
It returns the disassembly content in a string object.
"""
TestDisasm.py uses the disassemble() function to do disassembly on the SBSymbol, and
then the SBFunction object.
llvm-svn: 126955
// When stopped on breakppint 1, and then 2, we can get the line entries using
// SBFrame API SBFrame.GetLineEntry(). We'll get the start addresses for the
// two line entries; with the start address (of SBAddress type), we can then
// resolve the symbol context using the SBTarget API
// SBTarget.ResolveSymbolContextForAddress().
//
// The two symbol context should point to the same symbol, i.e., 'a' function.
Add two utility functions to lldbutil.py:
o get_stopped_threads(process, reason):
return the list of threads with the specified stop reason or an empty list if not found
o get_stopped_thread(process, reason):
return the first thread with the given stop reason or None if not found
llvm-svn: 126916
o int_to_bytearray()
o bytearray_to_int()
They return/interpret the bytearray in the little endian format.
For big endian, simply perform ba.reverse() on the bytearray object.
And modify TestProcessAPI.py to take advantage of the functions.
llvm-svn: 126813
among other SBProcess APIs, to write (int)256 into a memory location of a global variable
(int)my_int and reads/checks the variable afterwards.
llvm-svn: 126792
the SBProcess.ReadMemory() API, which, due to SWIG typemap'ing, expects 3 arguments (the location
to read from, the size in bytes to read, and an SBError object), and returns the result as a
Python string object.
On SnowLeopard where this has been tested, the SWIG script needs to be pampered (use the exact
same parameter names as in SBProcess.h) in order for this to work.
llvm-svn: 126736
current working directory when running the inferior. Radar filed:
# rdar://problem/9056462
# The process launch flag '-w' for setting the current working directory not working?
llvm-svn: 126529
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
a Stream, and then added GetOutputData & GetErrorData to get the accumulated data.
- Added a StreamTee that will tee output to two provided lldb::StreamSP's.
- Made the CommandObjectReturn use this so you can Tee the results immediately to
the debuggers output file, as well as saving up the results to return when the command
is done executing.
- HandleCommands now uses this so that if you have a set of commands that continue the target
you will see the commands come out as they are processed.
- The Driver now uses this to output the command results as you go, which makes the interface
more reactive seeming.
llvm-svn: 126015
- Objective-C constant strings were being
NULL-terminated erroneously.
- Empty Objective-C constant strings were not
being generated correctly.
Also added the template for a test of these
fixes.
llvm-svn: 125314
substitutions in order to achieve file mappings.
Modify CommandObjectTarget.cpp to properly set the status of the return object to make
scripting like this:
self.runCmd("target image-search-paths add %s %s" % (os.getcwd(), new_dir))
works.
llvm-svn: 124762
Currently this test case works fine run by itself, but fails when
run in the entire test suite; Johnny requested that I check it in
so that he can look at it.
llvm-svn: 124510
rdar://problem/8435794
settings set target.process.output-path does not seem to work
Also change the test case from test_set_output_path to test_set_error_output_path
as it now exercises both setting target.process.error-path and target.process.output-path.
llvm-svn: 124198
Enrico Granata