#
ed8a705c |
| 18-Sep-2010 |
Greg Clayton <gclayton@apple.com> |
General command line help cleanup: - All single character options will now be printed together - Changed all options that contains underscores to contain '-' instead - Made the help come out a little
General command line help cleanup: - All single character options will now be printed together - Changed all options that contains underscores to contain '-' instead - Made the help come out a little flatter by showing the long and short option on the same line. - Modified the short character for "--ignore-count" options to "-i"
llvm-svn: 114265
show more ...
|
#
a7015092 |
| 18-Sep-2010 |
Greg Clayton <gclayton@apple.com> |
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
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
show more ...
|
#
6f00abd5 |
| 14-Sep-2010 |
Greg Clayton <gclayton@apple.com> |
Fixed the implementation of "bool Block::Contains (const Block *block) const" to return the correct result.
Fixed "bool Variable::IsInScope (StackFrame *frame)" to return the correct result when the
Fixed the implementation of "bool Block::Contains (const Block *block) const" to return the correct result.
Fixed "bool Variable::IsInScope (StackFrame *frame)" to return the correct result when there are no location lists.
Modified the "frame variable" command such that: - if no arguments are given (dump all frame variables), then we only show variables that are currently in scope - if some arguments are given, we show an error if the variable is out of scope
llvm-svn: 113830
show more ...
|
#
016a95eb |
| 14-Sep-2010 |
Greg Clayton <gclayton@apple.com> |
Looking at some of the test suite failures in DWARF in .o files with the debug map showed that the location lists in the .o files needed some refactoring in order to work. The case that was failing
Looking at some of the test suite failures in DWARF in .o files with the debug map showed that the location lists in the .o files needed some refactoring in order to work. The case that was failing was where a function that was in the "__TEXT.__textcoal_nt" in the .o file, and in the "__TEXT.__text" section in the main executable. This made symbol lookup fail due to the way we were finding a real address in the debug map which was by finding the section that the function was in in the .o file and trying to find this in the main executable. Now the section list supports finding a linked address in a section or any child sections. After fixing this, we ran into issue that were due to DWARF and how it represents locations lists. DWARF makes a list of address ranges and expressions that go along with those address ranges. The location addresses are expressed in terms of a compile unit address + offset. This works fine as long as nothing moves around. When stuff moves around and offsets change between the remapped compile unit base address and the new function address, then we can run into trouble. To deal with this, we now store supply a location list slide amount to any location list expressions that will allow us to make the location list addresses into zero based offsets from the object that owns the location list (always a function in our case).
With these fixes we can now re-link random address ranges inside the debugger for use with our DWARF + debug map, incremental linking, and more.
Another issue that arose when doing the DWARF in the .o files was that GCC 4.2 emits a ".debug_aranges" that only mentions functions that are externally visible. This makes .debug_aranges useless to us and we now generate a real address range lookup table in the DWARF parser at the same time as we index the name tables (that are needed because .debug_pubnames is just as useless). llvm-gcc doesn't generate a .debug_aranges section, though this could be fixed, we aren't going to rely upon it.
Renamed a bunch of "UINT_MAX" to "UINT32_MAX".
llvm-svn: 113829
show more ...
|
#
9df87c17 |
| 13-Sep-2010 |
Greg Clayton <gclayton@apple.com> |
Make sure we have a variable list so we don't crash when a frame has no frame variables.
llvm-svn: 113736
|
#
5804fa41 |
| 13-Sep-2010 |
Greg Clayton <gclayton@apple.com> |
Removed unused variable.
llvm-svn: 113734
|
#
a134cc1b |
| 13-Sep-2010 |
Greg Clayton <gclayton@apple.com> |
Added a work in the DWARF parser when we parse an array that ends up having no elements so that they at least have 1 element.
Added the ability to show the declaration location of variables to the
Added a work in the DWARF parser when we parse an array that ends up having no elements so that they at least have 1 element.
Added the ability to show the declaration location of variables to the "frame variables" with the "--show-declaration" option ("-c" for short).
Changed the "frame variables" command over to use the value object code so that we use the same code path as the public API does when accessing and displaying variable values.
llvm-svn: 113733
show more ...
|
#
53c47f1e |
| 10-Sep-2010 |
Jim Ingham <jingham@apple.com> |
Move the "Object Description" into the ValueObject, and the add an API to SBValue to access it. For now this is just the result of ObjC NSPrintForDebugger, but could be extended. Also store the res
Move the "Object Description" into the ValueObject, and the add an API to SBValue to access it. For now this is just the result of ObjC NSPrintForDebugger, but could be extended. Also store the results of the ObjC Object Printer in a Stream, not a ConstString.
llvm-svn: 113660
show more ...
|
#
e3d26315 |
| 08-Sep-2010 |
Caroline Tice <ctice@apple.com> |
Clean up, clarify and standardize help text, and fix a few help text formatting problems.
llvm-svn: 113408
|
Revision tags: llvmorg-2.8.0-rc1, llvmorg-2.8.0-rc0 |
|
#
6dadd508 |
| 02-Sep-2010 |
Greg Clayton <gclayton@apple.com> |
Added a new bool parameter to many of the DumpStopContext() methods that might dump file paths that allows the dumping of full paths or just the basenames. Switched the stack frame dumping code to u
Added a new bool parameter to many of the DumpStopContext() methods that might dump file paths that allows the dumping of full paths or just the basenames. Switched the stack frame dumping code to use just the basenames for the files instead of the full path.
Modified the StackID class to no rely on needing the start PC for the current function/symbol since we can use the SymbolContextScope to uniquely identify that, unless there is no symbol context scope. In that case we can rely upon the current PC value. This saves the StackID from having to calculate the start PC when the StackFrame::GetStackID() accessor is called.
Also improved the StackID less than operator to correctly handle inlined stack frames in the same stack.
llvm-svn: 112867
show more ...
|
#
288bdf9c |
| 02-Sep-2010 |
Greg Clayton <gclayton@apple.com> |
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueOb
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects.
StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables.
The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow.
llvm-svn: 112800
show more ...
|
#
6d56d2ce |
| 02-Sep-2010 |
Jim Ingham <jingham@apple.com> |
Move "variable list" to "frame variable"
llvm-svn: 112782
|
#
e40e4218 |
| 30-Aug-2010 |
Jim Ingham <jingham@apple.com> |
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
|
#
2976d00a |
| 26-Aug-2010 |
Jim Ingham <jingham@apple.com> |
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 "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
show more ...
|
#
6611103c |
| 23-Jun-2010 |
Greg Clayton <gclayton@apple.com> |
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
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
show more ...
|
#
40af72e1 |
| 15-Jun-2010 |
Jim Ingham <jingham@apple.com> |
Move Args.{cpp,h} and Options.{cpp,h} to Interpreter where they really belong.
llvm-svn: 106034
|
#
30fdc8d8 |
| 08-Jun-2010 |
Chris Lattner <sabre@nondot.org> |
Initial checkin of lldb code from internal Apple repo.
llvm-svn: 105619
|