Commit Graph

357 Commits

Author SHA1 Message Date
Johnny Chen 725945d568 Fixed an lldb infrastructure bug, where the debugger should reaaly update its
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
2010-09-03 22:35:47 +00:00
Jim Ingham e40e42181f Added a way to open the current source file & line in an external editor, and you can turn this on with:
lldb -e

llvm-svn: 112502
2010-08-30 19:44:40 +00:00
Jim Ingham 2976d00adb Change "Current" as in GetCurrentThread, GetCurrentStackFrame, etc, to "Selected" i.e. GetSelectedThread. Selected makes more sense, since these are set by some user action (a selection). I didn't change "CurrentProcess" since this is always controlled by the target, and a given target can only have one process, so it really can't be selected.
llvm-svn: 112221
2010-08-26 21:32:51 +00:00
Greg Clayton 471b31ce62 Remove use of STL collection class use of the "data()" method since it isn't
part of C++'98. Most of these were "std::vector<T>::data()" and 
"std::string::data()".

llvm-svn: 108957
2010-07-20 22:52:08 +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
Chris Lattner 30fdc8d841 Initial checkin of lldb code from internal Apple repo.
llvm-svn: 105619
2010-06-08 16:52:24 +00:00