Added the ability to read memory from the target's object files when we aren't
running, so disassembling works before you run!
Cleaned up the API to lldb_private::Target::ReadMemory().
Cleaned up the API to the Disassembler to use actual "lldb_private::Address"
objects instead of just an "addr_t". This is nice because the Address objects
when resolved carry along their section and module which can get us the
object file. This allows Target::ReadMemory to be used when we are not
running.
Added a new lldb_private::Address dump style: DumpStyleDetailedSymbolContext
This will show a full breakdown of what an address points to. To see some
sample output, execute a "image lookup --address <addr>".
Fixed SymbolContext::DumpStopContext(...) to not require a live process in
order to be able to print function and symbol offsets.
llvm-svn: 107350
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
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
without having to use RTTI.
Removed the ThreadPlanContinue and replaced with a ShouldAutoContinue query that serves the same purpose. Having to push
another plan to assert that if there's no other indication the target should continue when this plan is popped was flakey
and error prone. This method is more stable, and fixed problems we were having with thread specific breakpoints.
llvm-svn: 106378
Push this through all the breakpoint management code. Allow this to be set when the breakpoint is created.
Fix the Process classes so that a breakpoint hit that is not for a particular thread is not reported as a
breakpoint hit event for that thread.
Added a "breakpoint configure" command to allow you to reset any of the thread
specific options (or the ignore count.)
llvm-svn: 106078
Greg Clayton