(lldb) breakpoint set -S description
and a compilation unit defined instance method with:
(lldb) breakpoint set -n '-[MyString initWithNSString:]'
llvm-svn: 114134
build tree relative search path in order to locate the lldb.py module. When
'-i' is present, the test driver relies on the PYTHONPATH environment variable
to locate the lldb.py module.
llvm-svn: 114094
This will remove the confusion experienced when previous test runs left some
files (both intermediate or by-product as a result of the test).
lldbtest.TestBase defines a classmethod tearDownClass(cls) which invokes the
platform-specific cleanup() function as defined by the plugin; after that, it
invokes a subclass-specific function classCleanup(cls) if defined; and, finally,
it restores the old working directory.
An example of classCleanup(cls) is in settings/TestSettings.py:
@classmethod
def classCleanup(cls):
system(["/bin/sh", "-c", "rm output.txt"])
where it deletes the by-product "output.txt" as a result of running a.out.
llvm-svn: 114058
(lldb) settings set process.run-args A B C
(lldb) settings set process.env-vars ["MY_ENV_VAR"]=YES
commands. The main.cpp checks whether A, B, C is passed to main and whether
the $MY_ENV_VAR env variable is defined and outputs the findings to a file.
llvm-svn: 114031
lldb.py module. The priorities to search for are Debug, Release, then
BuildAndIntegration. You can always override this with a valid PYTHONPATH
environment variable before running the test driver.
For example:
$ PYTHONPATH=/Find/My/LLDB/Module/Here ./dotest.py -v .
Python runtime will try to locate the lldb.py module from
/Find/My/LLDB/Module/Here first before trying the Debug, Release, and then
BuildAndIntegration directories.
llvm-svn: 113991
as it now passes. Added some extra tests to breakpoint_creation_by_filespec_python().
More clarification for the "os command" output and error as defined in
lldbtest.system() function.
Cleaned up the option processing of the test driver (dotest.py) and fixed the comment
about enabling gdb-remote logging. Example:
$ GDB_REMOTE_LOG=/tmp/log.txt ./dotest.py -v -t enum_types
llvm-svn: 113868
was used to set the selected thread if none was selected. Use a more robust
API to accomplish the task.
Also fixed an error found, while investigating, in CommandObjectThreadSelect::
Execute() where the return status was not properly set if successful.
As a result, both the stl step-in test cases with expectedFailure decorators now
passed.
llvm-svn: 113825
the binaries.
If the build* function is passed the compiler argument, for example, 'llvm-gcc',
it is passed as a make variable to the make command. Otherwise, we check the
LLDB_CC environment variable; if it is defined, it is passed as a make variable
to the make command.
If neither the compiler keyword argument nor the LLDB_CC environment variable is
specified, no CC make variable is passed to the make command. The Makefile gets
to define the default CC being used.
--------------------------------------------------------------------------------
Example usage follows:
o Via the keyword argument:
class ArrayTypesTestCase(TestBase):
mydir = "array_types"
@unittest2.skipUnless(sys.platform.startswith("darwin"), "requires Darwin")
def test_with_dsym_and_run_command(self):
"""Test 'frame variable var_name' on some variables with array types."""
self.buildDsym(compiler='llvm-gcc')
self.array_types()
...
o Via LLDB_CC environment variable:
$ LLDB_CC=llvm-gcc ./dotest.py -v -t array_types
----------------------------------------------------------------------
Collected 4 tests
test_with_dsym_and_python_api (TestArrayTypes.ArrayTypesTestCase)
Use Python APIs to inspect variables with array types. ...
os command: [['/bin/sh', '-c', 'make clean; make MAKE_DSYM=YES CC=llvm-gcc']]
output: rm -rf "a.out" "a.out.dSYM" main.o main.d
llvm-gcc -arch x86_64 -gdwarf-2 -O0 -arch x86_64 -gdwarf-2 -O0 -c -o main.o main.c
llvm-gcc -arch x86_64 -gdwarf-2 -O0 main.o -o "a.out"
/usr/bin/dsymutil -o "a.out.dSYM" "a.out"
...
llvm-svn: 113781
static class array. It turns out that gcc 4.2 will emit DWARF that correctly
describes the PointType, but it will incorrectly emit debug info for the
"g_points" array where the following things are wrong:
- the DW_TAG_array_type won't have a subrange info
- the DW_TAG_variable for "g_points" won't have a valid byte size, so even
though we know the size of PointType, we can't infer the actual size
of the array by dividing the size of the variable by the number of
elements.
We want to make sure clang and llvm-gcc handle this correctly.
llvm-svn: 113730
to specify a one-liner (either scripting or lldb command) inline.
Refactored CommandObjectBreakpointCommandAdd::Execute() a little bit and added
some comments.
Sn now, we use:
breakpoint command add -p 1 -o "conditional_break.stop_if_called_from_a()"
to specify a Python one-liner as the callback for breakpoint #1.
llvm-svn: 113672
command for a breakpoint, for example:
(lldb) breakpoint command add -p 1 "conditional_break.stop_if_called_from_a()"
The ScriptInterpreter interface has an extra method:
/// Set a one-liner as the callback for the breakpoint command.
virtual void
SetBreakpointCommandCallback (CommandInterpreter &interpreter,
BreakpointOptions *bp_options,
const char *oneliner);
to accomplish the above.
Also added a test case to demonstrate lldb's use of breakpoint callback command
to stop at function c() only when its immediate caller is function a(). The
following session shows the user entering the following commands:
1) command source .lldb (set up executable, breakpoint, and breakpoint command)
2) run (the callback mechanism will skip two breakpoints where c()'s immeidate caller is not a())
3) bt (to see that indeed c()'s immediate caller is a())
4) c (to continue and finish the program)
test/conditional_break $ ../../build/Debug/lldb
(lldb) command source .lldb
Executing commands in '.lldb'.
(lldb) file a.out
Current executable set to 'a.out' (x86_64).
(lldb) breakpoint set -n c
Breakpoint created: 1: name = 'c', locations = 1
(lldb) script import sys, os
(lldb) script sys.path.append(os.path.join(os.getcwd(), os.pardir))
(lldb) script import conditional_break
(lldb) breakpoint command add -p 1 "conditional_break.stop_if_called_from_a()"
(lldb) run
run
Launching '/Volumes/data/lldb/svn/trunk/test/conditional_break/a.out' (x86_64)
(lldb) Checking call frames...
Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread:
frame #0: a.out`c at main.c:39
frame #1: a.out`b at main.c:34
frame #2: a.out`a at main.c:25
frame #3: a.out`main at main.c:44
frame #4: a.out`start
c called from b
Continuing...
Checking call frames...
Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread:
frame #0: a.out`c at main.c:39
frame #1: a.out`b at main.c:34
frame #2: a.out`main at main.c:47
frame #3: a.out`start
c called from b
Continuing...
Checking call frames...
Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread:
frame #0: a.out`c at main.c:39
frame #1: a.out`a at main.c:27
frame #2: a.out`main at main.c:50
frame #3: a.out`start
c called from a
Stopped at c() with immediate caller as a().
a(1) returns 4
b(2) returns 5
Process 20420 Stopped
* thread #1: tid = 0x2e03, 0x0000000100000de8 a.out`c + 7 at main.c:39, stop reason = breakpoint 1.1, queue = com.apple.main-thread
36
37 int c(int val)
38 {
39 -> return val + 3;
40 }
41
42 int main (int argc, char const *argv[])
(lldb) bt
bt
thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread
frame #0: 0x0000000100000de8 a.out`c + 7 at main.c:39
frame #1: 0x0000000100000dbc a.out`a + 44 at main.c:27
frame #2: 0x0000000100000e4b a.out`main + 91 at main.c:50
frame #3: 0x0000000100000d88 a.out`start + 52
(lldb) c
c
Resuming process 20420
Process 20420 Exited
a(3) returns 6
(lldb)
llvm-svn: 113596
from scripting applications. An example usage from TestConditionalBreak.py is:
import lldbutil
lldbutil.PrintStackTrace(thread)
./dotest.py -v conditional_break
----------------------------------------------------------------------
Collected 2 tests
test_with_dsym (TestConditionalBreak.ConditionalBreakTestCase)
Exercise some thread and frame APIs to break if c() is called by a(). ... Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread:
frame #0: a.out`c at main.c:39
frame #1: a.out`b at main.c:34
frame #2: a.out`a at main.c:25
frame #3: a.out`main at main.c:44
frame #4: a.out`start
Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread:
frame #0: a.out`c at main.c:39
frame #1: a.out`b at main.c:34
frame #2: a.out`main at main.c:47
frame #3: a.out`start
Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread:
frame #0: a.out`c at main.c:39
frame #1: a.out`a at main.c:27
frame #2: a.out`main at main.c:50
frame #3: a.out`start
ok
test_with_dwarf (TestConditionalBreak.ConditionalBreakTestCase)
Exercise some thread and frame APIs to break if c() is called by a(). ... Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread:
frame #0: a.out`c at main.c:39
frame #1: a.out`b at main.c:34
frame #2: a.out`a at main.c:25
frame #3: a.out`main at main.c:44
frame #4: a.out`start
Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread:
frame #0: a.out`c at main.c:39
frame #1: a.out`b at main.c:34
frame #2: a.out`main at main.c:47
frame #3: a.out`start
Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread:
frame #0: a.out`c at main.c:39
frame #1: a.out`a at main.c:27
frame #2: a.out`main at main.c:50
frame #3: a.out`start
ok
----------------------------------------------------------------------
Ran 2 tests in 7.803s
OK
llvm-svn: 113432
objects and populates them so we can test making expression calls with these
objects. We will need to make this test case more complete as time goes on to
make sure we can evaluate all functions.
llvm-svn: 113314
execution context only when the process is still alive. When running the test
suite, the debugger is launching and killing processes constantly.
This might be the cause of the test hang as reported in rdar://problem/8377854,
where the debugger was looping infinitely trying to update a supposedly stale
thread list.
llvm-svn: 113022
method where they belong. Also fixed a logic error in maintaining the command
interface flag (runStarted) indicating whether the lldb "run"/"process launch"
command has been issued. It was erroneously cleared.
Modified the test cases to take advantage of the refactoring.
llvm-svn: 112863
argument when issuing a "run" lldb command within the test case meant to
exercise the Python APIs, but is using the command interface due to certain
reason (such as target.LaunchProcess() does not reliably bring up the inferior).
llvm-svn: 112682
to delegate the building of binaries to a sys.platform-sepcific plugin.
Modified the dotest.py test driver to add the "plugins" directory to the
PYTHONPATH as well.
darwin.py is the Mac OS X plugin module.
llvm-svn: 112606
taken from Python 2.7's subprocess.check_output() convenience function. The
purpose of this method is to run the os command with arguments and return its
output as a byte string.
Modified hello_world/TestHelloWorld.py to have two test cases:
o test_with_dsym_and_run_command
o test_with_dwarf_and_process_launch_api
with the dsym case conditioned on sys.platform.startswith("darwin") being true.
The two cases utilize the system() method to invoke "make clean; make MAKE_DYSM=YES/NO"
to prepare for the appropriate debugging format before running the test logic.
llvm-svn: 112530
breakpoint by FileSpec and line number and exercises some FileSpec APIs.
Also, RUN_STOPPED is a bad assert name, RUN_SUCCEEDED is better.
llvm-svn: 112327
and process. Added comment within the file about issues of using LaunchProcess
of SBTarget to launch a process (rdar://problem/8364687).
llvm-svn: 112276
with the only exception of launching the process from SBTarget which is under
investigation.
o build-swig-Python.sh should also checks the timestamp of ${swig_input_file}
for update eligibility. Also, once an update is in order, there's no need
to check the remaining header files for timestamps.
o Coaches swig to treat StopReason as an int type, instead of a C++ class.
llvm-svn: 112210
o SBDebugger.GetCurrentTarget()
o SBTarget.GetProcess()
o SBProcess.GetAddressByteSize()
in order to make sure that, indeed, 64-bit, followed by 32-bit processes have
been launched.
Added invoke() method to TestBase to factor in the tracing logic in one place.
This method allows an object to call a method with no arg reflectively.
llvm-svn: 112102
there's no point matching further sub strings; the expect() already fails.
Also cleaned up the assert message for VARIABLES_DISPLAYED_CORRECTLY.
llvm-svn: 112074
mechanism seems to work fine on my MacBook Pro in some limited test cases.
The default maxLaunchCount and timeWait variables used in the scheme can be
overridden by the env variables LLDB_MAX_LAUNCH_COUNT and LLDB_TIME_WAIT.
llvm-svn: 112071
which hosts the Makefile.rules and modified most of the Makefiles under each
test case directories to utilize Mekefile.rules.
Added a description of 'make' directory into README-TestSuite file.
llvm-svn: 111868
which, defaults to False, and if set to True, will trace lldb command execution
and result.
Added "-t" command option to the test driver dotest.py which sets the
LLDB_COMMAND_TRACE environment variable to "YES" and as a result always turns on
command tracing regardless of the 'trace' keyword argument to runCmd()/expect().
llvm-svn: 111811
Johnny Chen