'breakpoint delete 1' from 'breakpoint delete'. With 'breakpoint delete', the
command interpreter was asking for a confirmation from the user, which there
isn't any.
llvm-svn: 116610
breakpoint modify -c 'val == 3' 1
after:
breakpoint set -n c
which sets a breakpoint on function 'c'. The breakpoint should only stop if
expression 'val == 3' evaluates to true.
llvm-svn: 116607
since we can't parse DW_TAG_namespace DIEs as types. They are only decls in
clang. All of the types we handle right now have both clang "XXXType" classes
to go with the "XXXDecl" classes which means they can be used within the
lldb_private::Type class. I need to check to see which other decls that don't
have associated type objects need to float around the debugger and possibly
make a lldb_private::Decl class to manage them.
llvm-svn: 116558
session info after a test case failure, allowing more direct inspection of
debugger session which leads to the test failure.
For a simple usage scenario:
[18:06:26] johnny:/Volumes/data/lldb/svn/trunk/test $ ./dotest.py -v . 2> ~/Developer/Log/lldbtest.log
...
[18:14:43] johnny:/Volumes/data/lldb/svn/trunk/test $ ls -l .session-*
-rw-r--r-- 1 johnny admin 1359 Oct 14 18:06 .session-TestArrayTypes.ArrayTypesTestCase.test_with_dwarf_and_run_command
-rw-r--r-- 1 johnny admin 2054 Oct 14 18:07 .session-TestClassTypes.ClassTypesTestCase.test_with_dsym_and_expr_parser
-rw-r--r-- 1 johnny admin 2055 Oct 14 18:07 .session-TestClassTypes.ClassTypesTestCase.test_with_dwarf_and_expr_parser
-rw-r--r-- 1 johnny admin 1351 Oct 14 17:57 .session-TestClassTypes.ClassTypesTestCase.test_with_dwarf_and_run_command
[18:14:51] johnny:/Volumes/data/lldb/svn/trunk/test $
The test case which failed will have its recorded session info dumped to a
.session-* file in the current working directory. For test suite using
relocated directory, expect to find the .session-* files there.
In this checkin, I also add @skip decorator to the two test methods in
test/foundation/TestObjCMethods.py as it looks like the test suite is
deadlocking when running the tests. More investigations are needed.
llvm-svn: 116552
debug information and you evaluated an expression, a crash would occur as a
result of an unchecked pointer.
Added the ability to get the expression path for a ValueObject. For a rectangle
point child "x" the expression path would be something like: "rect.top_left.x".
This will allow GUI and command lines to get ahold of the expression path for
a value object without having to explicitly know about the hierarchy. This
means the ValueObject base class now has a "ValueObject *m_parent;" member.
All ValueObject subclasses now correctly track their lineage and are able
to provide value expression paths as well.
Added a new "--flat" option to the "frame variable" to allow for flat variable
output. An example of the current and new outputs:
(lldb) frame variable
argc = 1
argv = 0x00007fff5fbffe80
pt = {
x = 2
y = 3
}
rect = {
bottom_left = {
x = 1
y = 2
}
top_right = {
x = 3
y = 4
}
}
(lldb) frame variable --flat
argc = 1
argv = 0x00007fff5fbffe80
pt.x = 2
pt.y = 3
rect.bottom_left.x = 1
rect.bottom_left.y = 2
rect.top_right.x = 3
rect.top_right.y = 4
As you can see when there is a lot of hierarchy it can help flatten things out.
Also if you want to use a member in an expression, you can copy the text from
the "--flat" output and not have to piece it together manually. This can help
when you want to use parts of the STL in expressions:
(lldb) frame variable --flat
argc = 1
argv = 0x00007fff5fbffea8
hello_world._M_dataplus._M_p = 0x0000000000000000
(lldb) expr hello_world._M_dataplus._M_p[0] == '\0'
llvm-svn: 116532
if no update commands are specified it just lists the current values, and show that
it always shows the new values for a signal after it has been updated. Also updated
the help text to match the new functionality.
llvm-svn: 116520
Inside the lldb module, there's no need (and as a matter of fact, incorrect) to specify the 'lldb'
module name.
Comment out the call to lldb.SBDebugger.Initialize() within the test driver itself, since it is
already done when we import the lldb.py module.
llvm-svn: 116485
and 'process handle'. The test suite would like to control the asynch/sync
execution of the interpreter during the middle of the test method, so the
CommandInterpreter::SetSynchronous(bool value) is modified to allow the mode to
be changed more than once.
In practice, it would be advisable to control the process and to set the
async/sync mode from a single thread, too.
llvm-svn: 116467
Add missing break statment to case statement in Process::ShouldBroadcastEvent.
Add new command, "process handle" to allow users to control process behavior on
the receipt of various Unix signals (whether the process should stop; whether the
process should be passed the signal; whether the debugger user should be notified
that the signal came in).
llvm-svn: 116430
artifical members (like the vtable pointer member that shows up in the DWARF).
We were adding this to each class which was making all member variables be off
by a pointer size.
Added a test case so we can track this with "test/forward".
Fixed the type name index in DWARF to include all the types after finding
some types were being omitted due to the DW_AT_specification having the
DW_AT_declaration attribute which was being read into the real type instances
when there were forward declarations in the DWARF, causing the type to be
omitted. We now check to make sure any DW_AT_declaration values are only
respected when parsing types if the attribute is from the current DIE.
After fixing the missing types, we ran into some issues with the expression
parser finding duplicate entries for __va_list_tag since they are built in
types and would result in a "duplicate __va_list_tag definition" error. We
are now just ignoring this name during lookup, but we will need to see if
we can get the name lookup function to not get called in these cases.
Fixed an issue that would cause an assertion where DW_TAG_subroutine_types
that had no children, would not properly make a clang function type of:
"void (*) (void)".
llvm-svn: 116392
function to get the line numbers for breakpoints 1-5 during setUp().
Use a pattern to match the output from both gcc-compiled and clang-compiled binary.
This finishes the conversion of the test suite to avoid hardcoded line numbers
when setting breakpoints with either the lldb command:
breakpoint set -f filename -l lineno
or the Python API:
target.BreakpointCreateByLocation(filename, lineno)
llvm-svn: 116378
function to get the line number to break on during setUp().
Use a pattern to match the output from both gcc-compiled and clang-compiled binary.
llvm-svn: 116374
function to get the line number to break on during setUp().
Also modify main.c to use g_file_static_cstr within main() so clang does not
optimize this variable out.
llvm-svn: 116355
different configuration-based files using the config file. For example:
sys.stderr = open("/tmp/lldbtest-stderr", "w")
sys.stdout = open("/tmp/lldbtest-stdout", "w")
compilers = ["gcc", "llvm-gcc"]
archs = ["x86_64", "i386"]
split_stderr = True # This will split the stderr into configuration-specific file
split_stdout = True # This will split the stdout into configuration-specific file
will produce:
/tmp/lldbtest-stderr
/tmp/lldbtest-stderr.arch=i386-compiler=gcc
/tmp/lldbtest-stderr.arch=i386-compiler=llvm-gcc
/tmp/lldbtest-stderr.arch=x86_64-compiler=gcc
/tmp/lldbtest-stderr.arch=x86_64-compiler=llvm-gcc
/tmp/lldbtest-stdout
/tmp/lldbtest-stdout.arch=i386-compiler=gcc
/tmp/lldbtest-stdout.arch=i386-compiler=llvm-gcc
/tmp/lldbtest-stdout.arch=x86_64-compiler=gcc
/tmp/lldbtest-stdout.arch=x86_64-compiler=llvm-gcc
as a result of splitting stderr and stdout. In addition, each configuration can have
its individual top level relocated directory to house the test files as well as the
intermediate files by using '-r dir' to relocate the tests into a new relocated directory
instead of running the tests in place.
llvm-svn: 116341
Jim Ingham