History log of /llvm-project/lldb/source/Commands/CommandObjectFrame.cpp (Results 251 – 267 of 267)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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


1...<<11