Fixed a case where Mangled::GetName(...) could return a invalid demangled name when one could be calculated.

llvm-svn: 113900

llvm-svn: 113899

to symbolicate things without the need for a valid process subclass.

llvm-svn: 113895

Added the ability to specify a preference for mangled or demangled to Mangled::GetName.
Changed one place where mangled was prefered in GetName.
The Dynamic loader should look up the target of a stub by mangled name if it exists.

llvm-svn: 113869

llvm-svn: 113832

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

was used to set the selected thread if none was selected.  Use a more robust
API to accomplish the task.

Also fixed an error found, while investigating, in CommandObjectThreadSelect::
Execute() where the return status was not properly set if successful.

As a result, both the stl step-in test cases with expectedFailure decorators now
passed.

llvm-svn: 113825

point to.

llvm-svn: 113735

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

it with llvm::sys::Program::FindProgramByName.

llvm-svn: 113709

They will now be represented as:
eSymbolTypeFunction: eSymbolTypeCode with IsDebug() == true
  eSymbolTypeGlobal: eSymbolTypeData with IsDebug() == true and IsExternal() == true
  eSymbolTypeStatic: eSymbolTypeData with IsDebug() == true and IsExternal() == false

This simplifies the logic when dealing with symbols and allows for symbols
to be coalesced into a single symbol most of the time.

Enabled the minimal symbol table for mach-o again after working out all the
kinks. We now get nice concise symbol tables and debugging with DWARF in the
.o files with a debug map in the binary works well again. There were issues
where the SymbolFileDWARFDebugMap symbol file parser was using symbol IDs and
symbol indexes interchangeably. Now that all those issues are resolved 
debugging is working nicely.

llvm-svn: 113678

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

When the debugger updates its symbol context, if no thread or frame are selected select the first thread's 0th frame.

llvm-svn: 113657

up a seciton offset address (SBAddress) within a module that returns a
symbol context (SBSymbolContext). Also added a SBSymbolContextList in 
preparation for adding find/lookup APIs that can return multiple results.

Added a lookup example code that shows how to do address lookups.

llvm-svn: 113599

The Unwind and RegisterContext subclasses still need
to be finished; none of this code is used by lldb at
this point (unless you call into it by hand).

The ObjectFile class now has an UnwindTable object.

The UnwindTable object has a series of FuncUnwinders
objects (Function Unwinders) -- one for each function
in that ObjectFile we've backtraced through during this
debug session.

The FuncUnwinders object has a few different UnwindPlans.
UnwindPlans are a generic way of describing how to find
the canonical address of a given function's stack frame
(the CFA idea from DWARF/eh_frame) and how to restore the
caller frame's register values, if they have been saved
by this function.

UnwindPlans are created from different sources.  One source is the
eh_frame exception handling information generated by the compiler
for unwinding an exception throw.  Another source is an assembly
language inspection class (UnwindAssemblyProfiler, uses the Plugin
architecture) which looks at the instructions in the funciton
prologue and describes the stack movements/register saves that are
done.

Two additional types of UnwindPlans that are worth noting are
the "fast" stack UnwindPlan which is useful for making a first
pass over a thread's stack, determining how many stack frames there
are and retrieving the pc and CFA values for each frame (enough
to create StackFrameIDs).  Only a minimal set of registers is
recovered during a fast stack walk.  

The final UnwindPlan is an architectural default unwind plan.
These are provided by the ArchDefaultUnwindPlan class (which uses
the plugin architecture).  When no symbol/function address range can
be found for a given pc value -- when we have no eh_frame information
and when we don't have a start address so we can't examine the assembly
language instrucitons -- we have to make a best guess about how to 
unwind.  That's when we use the architectural default UnwindPlan.
On x86_64, this would be to assume that rbp is used as a stack pointer
and we can use that to find the caller's frame pointer and pc value.
It's a last-ditch best guess about how to unwind out of a frame.

There are heuristics about when to use one UnwindPlan versues the other --
this will all happen in the still-begin-written UnwindLLDB subclass of
Unwind which runs the UnwindPlans.

llvm-svn: 113581

and the user didn't specify a particular directory, search for the file 
using the $PATH environment variable.

llvm-svn: 113575

cleaning up the output of many GetDescription objects that are part of a 
symbol context. This fixes an issue where no ranges were being printed out
for functions, blocks and symbols.

llvm-svn: 113571

to be set up the way they are.  Comment out code that removes pending
settings for live instances (after the settings are copied over).

llvm-svn: 113519

Make get/set variable at the debugger level always set the particular debugger's instance variables rather than
the default variables.

llvm-svn: 113474

Make sure creating a pending instance doesn't also trigger creating a live instance; also make sure creating a
pending instance uses the specified instance name rather than creating a new one; add brackets to instance names
when searching for and removing pending instances.

llvm-svn: 113370

member variables.

Modified lldb_private::Module to have an accessor that can be used to tell if
a module is a dynamic link editor (dyld) as there are functions in dyld on
darwin that mirror functions in libc (malloc, free, etc) that should not
be used when doing function lookups by name in expressions if there are more
than one match when looking up functions by name.

llvm-svn: 113313

llvm-svn: 113309

llvm-svn: 113292

in UserSettingsController.cpp.

llvm-svn: 113268

llvm-svn: 113245

Fixed an error that could occur during disassembly that could cause a function name to be printed before the first _and_ the second instruction of disassembly when there are two symbols -- one debug symbol and one linker symbol. 

llvm-svn: 113181

This is a very large commit that completely re-does the way lldb
handles user settable internal variables (the equivalent of set/show
variables in gdb).  In addition to the basic infrastructure (most of
which is defined in UserSettingsController.{h,cpp}, there are examples
of two classes that have been set up to contain user settable
variables (the Debugger and Process classes).  The 'settings' command
has been modified to be a command-subcommand structure, and the 'set',
'show' and 'append' commands have been moved into this sub-commabnd
structure.  The old StateVariable class has been completely replaced
by this, and the state variable dictionary has been removed from the
Command Interpreter.  Places that formerly accessed the state variable
mechanism have been modified to access the variables in this new
structure instead (checking the term-width; getting/checking the
prompt; etc.)

Variables are attached to classes; there are two basic "flavors" of
variables that can be set: "global" variables (static/class-wide), and
"instance" variables (one per instance of the class).  The whole thing
has been set up so that any global or instance variable can be set at
any time (e.g. on start up, in your .lldbinit file), whether or not
any instances actually exist (there's a whole pending and default
values mechanism to help deal with that).

llvm-svn: 113041

llvm-svn: 113032

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

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

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

llvm-svn: 112679

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

documentation. Symbol now inherits from the symbol
context scope so that the StackID can use a "SymbolContextScope *"
instead of a blockID (which could have been the same as some other
blockID from another symbol file). 

Modified the stacks that are created on subsequent stops to reuse
the previous stack frame objects which will allow for some internal
optimization using pointer comparisons during stepping. 

llvm-svn: 112495

llvm-svn: 112331

swaps on the variable list, value object list, and disassembly. This avoids
us having to try and update frame indexes and other things that were getting
out of sync.

llvm-svn: 112301

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

has inlined functions that all started at the same address, then the inlined
backtrace would not produce correct stack frames.

Also cleaned up and inlined a lot of stuff in lldb_private::Address.

Added a function to StackFrame to detect if the frame is a concrete frame so
we can detect the difference between actual frames and inlined frames.

llvm-svn: 111989

complex inlined examples.

StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()".
This is because inlined frames will have a PC value that is the same as the 
concrete frame that owns the inlined frame, yet the code locations for the
frame can be different. We also need to be able to get the real PC value for
a given frame so that variables evaluate correctly. To get the actual PC
value for a frame you can use:

    addr_t pc = frame->GetRegisterContext()->GetPC();

Some issues with the StackFrame stomping on its own symbol context were 
resolved which were causing the information to change for a frame when the
stack ID was calculated. Also the StackFrame will now correctly store the
symbol context resolve flags for any extra bits of information that were 
looked up (if you ask for a block only and you find one, you will alwasy have
the compile unit and function).

llvm-svn: 111964

which is now on by default. Frames are gotten from the unwinder as concrete
frames, then if inline frames are to be shown, extra information to track
and reconstruct these frames is cached with each Thread and exanded as needed.

I added an inline height as part of the lldb_private::StackID class, the class
that helps us uniquely identify stack frames. This allows for two frames to
shared the same call frame address, yet differ only in inline height.

Fixed setting breakpoint by address to not require addresses to resolve.

A quick example:

% cat main.cpp

% ./build/Debug/lldb test/stl/a.out 
Current executable set to 'test/stl/a.out' (x86_64).
(lldb) breakpoint set --address 0x0000000100000d31
Breakpoint created: 1: address = 0x0000000100000d31, locations = 1
(lldb) r
Launching 'a.out'  (x86_64)
(lldb) Process 38031 Stopped
* thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread
 277   	
 278   	      _CharT*
 279   	      _M_data() const
 280 ->	      { return  _M_dataplus._M_p; }
 281   	
 282   	      _CharT*
 283   	      _M_data(_CharT* __p)
(lldb) bt
thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread
  frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280
  frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288
  frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606
  frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414
  frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14
  frame #5: pc = 0x0000000100000d08, where = a.out`start + 52

Each inline frame contains only the variables that they contain and each inlined
stack frame is treated as a single entity.

llvm-svn: 111877