Skip to content
  1. Sep 12, 2010
  2. Sep 11, 2010
  3. Sep 10, 2010
    • Greg Clayton's avatar
      There was a check to make sure that the frame had a valid function before the... · b57a127a
      Greg Clayton authored
      There was a check to make sure that the frame had a valid function before the expression parser would allow decl lookups which was not needed. After removing this you can evaluate expressions correctly when stopped in a frame that only has a symbol or has no symbol context at all.
      
      llvm-svn: 113611
      b57a127a
    • Johnny Chen's avatar
      Fixed the breakage of "breakpoint command add -p 1 2" caused by r113596 as · 0e1cb4e0
      Johnny Chen authored
      pointed out by Jim Ingham.  The convenient one-liner specification should only
      apply when there is only one breakpoint id being specified for the time being.
      
      llvm-svn: 113609
      0e1cb4e0
    • Johnny Chen's avatar
      3495f25a
    • Greg Clayton's avatar
      Added some missing API for address resolving within a module, and looking · 09960031
      Greg Clayton authored
      up a seciton offset address (SBAddress) within a module that returns a
      symbol context (SBSymbolContext). Also added a SBSymbolContextList in 
      preparation for adding find/lookup APIs that can return multiple results.
      
      Added a lookup example code that shows how to do address lookups.
      
      llvm-svn: 113599
      09960031
    • 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
    • Johnny Chen's avatar
      Don't flatten lldb and import everything into the global namespace. Instead, · d0211cc6
      Johnny Chen authored
      set the debugger_unique_id with the lldb prefix.
      
      llvm-svn: 113589
      d0211cc6
    • Jason Molenda's avatar
      The first part of an lldb native stack unwinder. · fbcb7f2c
      Jason Molenda authored
      The Unwind and RegisterContext subclasses still need
      to be finished; none of this code is used by lldb at
      this point (unless you call into it by hand).
      
      The ObjectFile class now has an UnwindTable object.
      
      The UnwindTable object has a series of FuncUnwinders
      objects (Function Unwinders) -- one for each function
      in that ObjectFile we've backtraced through during this
      debug session.
      
      The FuncUnwinders object has a few different UnwindPlans.
      UnwindPlans are a generic way of describing how to find
      the canonical address of a given function's stack frame
      (the CFA idea from DWARF/eh_frame) and how to restore the
      caller frame's register values, if they have been saved
      by this function.
      
      UnwindPlans are created from different sources.  One source is the
      eh_frame exception handling information generated by the compiler
      for unwinding an exception throw.  Another source is an assembly
      language inspection class (UnwindAssemblyProfiler, uses the Plugin
      architecture) which looks at the instructions in the funciton
      prologue and describes the stack movements/register saves that are
      done.
      
      Two additional types of UnwindPlans that are worth noting are
      the "fast" stack UnwindPlan which is useful for making a first
      pass over a thread's stack, determining how many stack frames there
      are and retrieving the pc and CFA values for each frame (enough
      to create StackFrameIDs).  Only a minimal set of registers is
      recovered during a fast stack walk.  
      
      The final UnwindPlan is an architectural default unwind plan.
      These are provided by the ArchDefaultUnwindPlan class (which uses
      the plugin architecture).  When no symbol/function address range can
      be found for a given pc value -- when we have no eh_frame information
      and when we don't have a start address so we can't examine the assembly
      language instrucitons -- we have to make a best guess about how to 
      unwind.  That's when we use the architectural default UnwindPlan.
      On x86_64, this would be to assume that rbp is used as a stack pointer
      and we can use that to find the caller's frame pointer and pc value.
      It's a last-ditch best guess about how to unwind out of a frame.
      
      There are heuristics about when to use one UnwindPlan versues the other --
      this will all happen in the still-begin-written UnwindLLDB subclass of
      Unwind which runs the UnwindPlans.
      
      llvm-svn: 113581
      fbcb7f2c
    • Caroline Tice's avatar
      If the file the user specifies can't be found in the current directory, · 428a9a58
      Caroline Tice authored
      and the user didn't specify a particular directory, search for the file 
      using the $PATH environment variable.
      
      llvm-svn: 113575
      428a9a58
    • Greg Clayton's avatar
      Cleaned up the output of "image lookup --address <ADDR>" which involved · c9800667
      Greg Clayton authored
      cleaning up the output of many GetDescription objects that are part of a 
      symbol context. This fixes an issue where no ranges were being printed out
      for functions, blocks and symbols.
      
      llvm-svn: 113571
      c9800667
  4. Sep 09, 2010
  5. Sep 08, 2010
Loading