Skip to content
  1. Sep 16, 2010
    • Johnny Chen's avatar
      Provided a mechanism for the test class to cleanup after itself once it's done. · 1a9f4dd5
      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
      1a9f4dd5
    • Johnny Chen's avatar
      Simplied main() and emits a message to the standard out. · f7f62710
      Johnny Chen authored
      llvm-svn: 114033
      f7f62710
    • Johnny Chen's avatar
      Added two test cases to TestSettings.py which exercise the lldb's: · d5e111c2
      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
      d5e111c2
  2. Sep 15, 2010
  3. Sep 14, 2010
    • Johnny Chen's avatar
      Fixed an error in Debugger::UpdateExecutionContext() where an invalid index ID 0 · c13ee52c
      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
      c13ee52c
  4. Sep 13, 2010
    • Johnny Chen's avatar
      Extend the build mechanism to allow for specifying the compiler used to build · 1394a4b7
      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
      1394a4b7
    • Johnny Chen's avatar
      Updated the expected matching strings. · 9440d1c0
      Johnny Chen authored
      llvm-svn: 113756
      9440d1c0
    • Johnny Chen's avatar
      Updated the expected matching strings. · 661f8069
      Johnny Chen authored
      llvm-svn: 113755
      661f8069
    • Johnny Chen's avatar
      Updated the expected matching strings, and added a radar comment. · 8458405a
      Johnny Chen authored
      llvm-svn: 113753
      8458405a
    • Johnny Chen's avatar
      Updated the expected matching strings. · e00234e0
      Johnny Chen authored
      llvm-svn: 113751
      e00234e0
    • Johnny Chen's avatar
    • Johnny Chen's avatar
      9aae728e
    • Greg Clayton's avatar
      A few modifications to the class arrays test case. · 0c5550a9
      Greg Clayton authored
      llvm-svn: 113732
      0c5550a9
    • Greg Clayton's avatar
      I made this example after noting that I was unable to display an unsized · ac32b4dd
      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
      ac32b4dd
  5. Sep 11, 2010
    • Johnny Chen's avatar
      Added [-o <one-liner>] to the "breakpoint command add" lldb command to be able · 39d7d4f0
      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
      39d7d4f0
  6. Sep 10, 2010
    • Johnny Chen's avatar
      These two files should have been in r113596. Oops! · bc1857ba
      Johnny Chen authored
      llvm-svn: 113598
      bc1857ba
    • Johnny Chen's avatar
      Added the capability to specify a one-liner Python script as the callback · 94de55d5
      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
      94de55d5
  7. Sep 09, 2010
    • Johnny Chen's avatar
      Added GetStackFrames(thread) utility function. · 43a651c6
      Johnny Chen authored
      llvm-svn: 113460
      43a651c6
    • Johnny Chen's avatar
      Added a lldbutil.py module, which contains utility functions which can be used · 30ee4ef3
      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
      30ee4ef3
  8. Sep 08, 2010
  9. Sep 07, 2010
Loading