Commit Graph

114 Commits

Author SHA1 Message Date
Caroline Tice 650b92683a Re-write/clean up code that generated Python breakpoint commands.
Add a warning if no command was attached to the breakpoint.
Update the help slightly.

llvm-svn: 114467
2010-09-21 19:25:28 +00:00
Greg Clayton a701509229 Fixed the way set/show variables were being accessed to being natively
accessed by the objects that own the settings. The previous approach wasn't
very usable and made for a lot of unnecessary code just to access variables
that were already owned by the objects.

While I fixed those things, I saw that CommandObject objects should really
have a reference to their command interpreter so they can access the terminal
with if they want to output usaage. Fixed up all CommandObjects to take
an interpreter and cleaned up the API to not need the interpreter to be
passed in.

Fixed the disassemble command to output the usage if no options are passed
down and arguments are passed (all disassebmle variants take options, there
are no "args only").

llvm-svn: 114252
2010-09-18 01:14:36 +00:00
Caroline Tice e7e92b771a Remove help text that is no longer correct.
Fix Python script interpreter to not fail when the Debugger does
not have input/output file handles.

llvm-svn: 113880
2010-09-14 22:49:06 +00:00
Johnny Chen 4550154d31 Fixed some comments.
llvm-svn: 113673
2010-09-11 00:23:59 +00:00
Johnny Chen 94de55d5c2 Added the capability to specify a one-liner Python script as the callback
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
2010-09-10 18:21:10 +00:00
Johnny Chen d0211cc657 Don't flatten lldb and import everything into the global namespace. Instead,
set the debugger_unique_id with the lldb prefix.

llvm-svn: 113589
2010-09-10 16:19:10 +00:00
Johnny Chen 705c3b6aaa There is no need to restore (sys.stdin, sys.stdout) of the python script
interpreter right before calling Py_Finalize().  This also fixed the crash as
reported in rdar://problem/8252903.

llvm-svn: 110731
2010-08-10 21:26:55 +00:00
Johnny Chen 7dc2e4784e We can do better when reporting the status of one-liner script execution.
Change the prototype of ScriptInterpreter::ExecuteOneLine() to return bool
instead of void and take one additional parameter as CommandReturnObject *.

Propagate the status of one-liner execution back appropriately.

llvm-svn: 109899
2010-07-30 22:33:14 +00:00
Greg Clayton a624358728 Added some comments to clarify where "init_lldb" comes from.
llvm-svn: 107801
2010-07-07 18:40:03 +00:00
Caroline Tice ebc1bb277c Add a unique ID to each debugger instance.
Add functions to look up debugger by id
Add global variable to lldb python module, to hold debugger id
Modify embedded Python interpreter to update the global variable with the
 id of its current debugger.
Modify the char ** typemap definition in lldb.swig to accept 'None' (for NULL)
 as a valid value.

The point of all this is so that, when you drop into the embedded interpreter
from the command interpreter (or when doing Python-based breakpoint commands),
there is a way for the Python side to find/get the correct debugger
instance ( by checking debugger_unique_id, then calling 
SBDebugger::FindDebuggerWithID  on it).

llvm-svn: 107287
2010-06-30 16:22:25 +00:00
Greg Clayton 6611103cfe Very large changes that were needed in order to allow multiple connections
to the debugger from GUI windows. Previously there was one global debugger
instance that could be accessed that had its own command interpreter and
current state (current target/process/thread/frame). When a GUI debugger
was attached, if it opened more than one window that each had a console
window, there were issues where the last one to setup the global debugger
object won and got control of the debugger.

To avoid this we now create instances of the lldb_private::Debugger that each 
has its own state:
- target list for targets the debugger instance owns
- current process/thread/frame
- its own command interpreter
- its own input, output and error file handles to avoid conflicts
- its own input reader stack

So now clients should call:

    SBDebugger::Initialize(); // (static function)

    SBDebugger debugger (SBDebugger::Create());
    // Use which ever file handles you wish
    debugger.SetErrorFileHandle (stderr, false);
    debugger.SetOutputFileHandle (stdout, false);
    debugger.SetInputFileHandle (stdin, true);

    // main loop
    
    SBDebugger::Terminate(); // (static function)
    
SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to
ensure nothing gets destroyed too early when multiple clients might be
attached.

Cleaned up the command interpreter and the CommandObject and all subclasses
to take more appropriate arguments.

llvm-svn: 106615
2010-06-23 01:19:29 +00:00
Jason Molenda b1823404c3 Committing patch from Joseph Ranieri to handle 'exit()' the same
as 'quit()' in the python script environment.

llvm-svn: 105756
2010-06-09 21:56:00 +00:00
Eli Friedman d0edb5b4a8 Don't include Python.h in the shared header.
llvm-svn: 105737
2010-06-09 18:31:38 +00:00
Chris Lattner 30fdc8d841 Initial checkin of lldb code from internal Apple repo.
llvm-svn: 105619
2010-06-08 16:52:24 +00:00