- Sep 16, 2010
-
-
Johnny Chen authored
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
-
Johnny Chen authored
llvm-svn: 114033
-
Johnny Chen authored
(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
-
- Sep 15, 2010
-
-
Johnny Chen authored
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
-
Johnny Chen authored
llvm-svn: 113989
-
Johnny Chen authored
has been fixed by r113947. But just in case it still fails, emits a prominent message always. llvm-svn: 113986
-
Johnny Chen authored
been fixed. llvm-svn: 113981
-
Johnny Chen authored
llvm-svn: 113906
-
Johnny Chen authored
decorators for the time being. llvm-svn: 113905
-
Johnny Chen authored
llvm-svn: 113901
-
Johnny Chen authored
llvm-svn: 113884
-
Johnny Chen authored
llvm-svn: 113881
-
Johnny Chen authored
llvm-svn: 113879
-
Johnny Chen authored
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
-
- Sep 14, 2010
-
-
Johnny Chen authored
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
-
- Sep 13, 2010
-
-
Johnny Chen authored
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
-
Johnny Chen authored
llvm-svn: 113756
-
Johnny Chen authored
llvm-svn: 113755
-
Johnny Chen authored
llvm-svn: 113753
-
Johnny Chen authored
llvm-svn: 113751
-
Johnny Chen authored
llvm-svn: 113750
-
Johnny Chen authored
llvm-svn: 113748
-
Greg Clayton authored
llvm-svn: 113732
-
Greg Clayton authored
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
-
- Sep 11, 2010
-
-
Johnny Chen authored
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
-
- Sep 10, 2010
-
-
Johnny Chen authored
llvm-svn: 113598
-
Johnny Chen authored
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
-
- Sep 09, 2010
-
-
Johnny Chen authored
llvm-svn: 113460
-
Johnny Chen authored
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
-
- Sep 08, 2010
-
-
Johnny Chen authored
of 10 seconds in order for the debugger to attach. llvm-svn: 113407
-
Johnny Chen authored
llvm-svn: 113327
-
Johnny Chen authored
the call site of c() is a(). llvm-svn: 113325
-
Greg Clayton authored
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
-
- Sep 07, 2010
-
-
Johnny Chen authored
And added a trace output for the stop function name to breakAfterLaunch() method. llvm-svn: 113251
-
Johnny Chen authored
llvm-svn: 113244
-
Johnny Chen authored
llvm-svn: 113241
-
Johnny Chen authored
llvm-svn: 113238
-
Johnny Chen authored
llvm-svn: 113219
-
Johnny Chen authored
llvm-svn: 113214
-
Johnny Chen authored
llvm-svn: 113211
-