RegisterContextKDP_i386 was not correctly writing registers due to missing "virtual" keywords. Added the virtual keywords and made the functions pure virtual to ensure subclasses can't get away without implementing these functions.
llvm-svn: 167066
Full UnwindPlan is trying to do an impossible unwind; in that case
invalidate the Full UnwindPlan and replace it with the architecture
default unwind plan.
This is a scenario that happens occasionally with arm unwinds in
particular; the instruction analysis based full unwindplan can
mis-parse the functions and the stack walk stops prematurely. Now
we can do a simpleminded frame-chain walk to find the caller frame
and continue the unwind. It's not ideal but given the complicated
nature of analyzing the arm functions, and the lack of eh_frame
information on iOS, it is a distinct improvement and fixes some
long-standing problems with the unwinder on that platform.
This is fixing <rdar://problem/12091421>. I may re-use this
invalidate feature in the future if I can identify other cases where
the full unwindplan's unwind information is clearly incorrect.
This checkin also includes some cleanup for the volatile register
definition in the arm ABI plugin for <rdar://problem/10652166>
although work remains to be done for that bug.
llvm-svn: 166757
must push something on the stack for a function call or not. In
x86, the stack pointer is decremented when the caller's pc is saved
on the stack. In arm, the stack pointer and frame pointer don't
necessarily have to change for a function call, although most
functions need to use some stack space during their execution.
Use this information in the RegisterContextLLDB to detect invalid
unwind scenarios more accurately.
<rdar://problem/12348574>
llvm-svn: 166005
Then make the Thread a Broadcaster, and get it to broadcast when the selected frame is changed (but only from the Command Line) and when Thread::ReturnFromFrame
changes the stack.
Made the Driver use this notification to print the new thread status rather than doing it in the command.
Fixed a few places where people were setting their broadcaster class by hand rather than using the static broadcaster class call.
<rdar://problem/12383087>
llvm-svn: 165640
it is unconditionally present now.
ObjectContainerBSDArchive::CreateInstance %z8.8x is not a valid printf arg specifier, %8.8zx would work
for size_t arg but this arg is addr_t. use %8.8llx and cast up to uint64_t.
ObjectFile::FindPlugin ditto.
DynamicRegisterInfo::SetRegisterInfo ifdef this function out if LLDB_DISABLE_PYTHON.
llvm-svn: 163599
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
Added code the initialize the register context in the OperatingSystemPython plug-in with the new PythonData classes, and added a test OperatingSystemPython module in lldb/examples/python/operating_system.py that we can use for testing.
llvm-svn: 162530
when you want to find the caller's saved pc, you look up the return address
register and use that. On arm, for instance, this would be the contents of
the link register (lr).
If the eh_frame CIE defines an RA, record that fact in the UnwindPlan.
When we're finding a saved register, if it's the pc, lok for the location
of the return address register instead.
<rdar://problem/12062310>
llvm-svn: 162167
a shared pointer to ease some memory management issues with a patch
I'm working on.
The main complication with using SPs for these objects is that most
methods that build up an UnwindPlan will construct a Row to a given
instruction point in a function, then add additional regsaves in
the next instruction point to that row and push it again. A little
care is needed to not mutate the previous instruction point's Row
once these are switched to being held behing shared pointers.
llvm-svn: 160214
This fix really needed to happen as a previous fix I had submitted for
calculating symbol sizes made many symbols appear to have zero size since
the function that was calculating the symbol size was calling another function
that would cause the calculation to happen again. This resulted in some symbols
having zero size when they shouldn't. This could then cause infinite stack
traces and many other side affects.
llvm-svn: 152244
which require a valid CFA address to create a stack frame. On connecting
to just-starting-up hardware we may have a stack pointer/frame pointer of 0
but we should still create a stack frame so other code in lldb can retrieve
register values via a stackframe.
llvm-svn: 151796
an unwind because RegisterContextLLDB::InitializeZerothFrame() would
create a minimal stack frame to fetch the pc value of the current
instruction. This proved fragile when another section of code was
trying to create the first stack frame and UnwindLLDB called
RegisterContextLLDB which tried to create its minimal stack frame.
Instead, get the live RegisterContext, retrieve the pc value from
the registers, and create an Address object from that.
llvm-svn: 151714
Initial step -- infrastructure change -- to fix the bug. Change the RegisterInfo data structure
to contain two additional fields (uint32_t *value_rges and uint32_t *invalidate_regs) to facilitate
architectures which have register mapping.
Update all existing RegsiterInfo arrays to have two extra NULL's (the additional fields) in each row,
GDBRemoteRegisterContext.cpp is modified to add d0-d15 and q0-q15 register info entries which take
advantage of the value_regs field to specify the containment relationship:
d0 -> (s0, s1)
...
d15 -> (s30, s31)
q0 -> (d0, d1)
...
q15 -> (d30, d31)
llvm-svn: 151686
I started work on being able to add symbol files after a debug session
had started with a new "target symfile add" command and quickly ran into
problems with stale Address objects in breakpoint locations that had
lldb_private::Section pointers into modules that had been removed or
replaced. This also let to grabbing stale modules from those sections.
So I needed to thread harded the Address, Section and related objects.
To do this I modified the ModuleChild class to now require a ModuleSP
on initialization so that a weak reference can created. I also changed
all places that were handing out "Section *" to have them hand out SectionSP.
All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild
so all of the find plug-in, static creation function and constructors now
require ModuleSP references instead of Module *.
Address objects now have weak references to their sections which can
safely go stale when a module gets destructed.
This checkin doesn't complete the "target symfile add" command, but it
does get us a lot clioser to being able to do such things without a high
risk of crashing or memory corruption.
llvm-svn: 151336
objects for the backlink to the lldb_private::Process. The issues we were
running into before was someone was holding onto a shared pointer to a
lldb_private::Thread for too long, and the lldb_private::Process parent object
would get destroyed and the lldb_private::Thread had a "Process &m_process"
member which would just treat whatever memory that used to be a Process as a
valid Process. This was mostly happening for lldb_private::StackFrame objects
that had a member like "Thread &m_thread". So this completes the internal
strong/weak changes.
Documented the ExecutionContext and ExecutionContextRef classes so that our
LLDB developers can understand when and where to use ExecutionContext and
ExecutionContextRef objects.
llvm-svn: 151009
indicate whether inline functions are desired.
This allows the expression parser, for instance,
to filter out inlined functions when looking for
functions it can call.
llvm-svn: 150279
user space programs. The core file support is implemented by making a process
plug-in that will dress up the threads and stack frames by using the core file
memory.
Added many default implementations for the lldb_private::Process functions so
that plug-ins like the ProcessMachCore don't need to override many many
functions only to have to return an error.
Added new virtual functions to the ObjectFile class for extracting the frozen
thread states that might be stored in object files. The default implementations
return no thread information, but any platforms that support core files that
contain frozen thread states (like mach-o) can make a module using the core
file and then extract the information. The object files can enumerate the
threads and also provide the register state for each thread. Since each object
file knows how the thread registers are stored, they are responsible for
creating a suitable register context that can be used by the core file threads.
Changed the process CreateInstace callbacks to return a shared pointer and
to also take an "const FileSpec *core_file" parameter to allow for core file
support. This will also allow for lldb_private::Process subclasses to be made
that could load crash logs. This should be possible on darwin where the crash
logs contain all of the stack frames for all of the threads, yet the crash
logs only contain the registers for the crashed thrad. It should also allow
some variables to be viewed for the thread that crashed.
llvm-svn: 150154
due to RTTI worries since llvm and clang don't use RTTI, but I was able to
switch back with no issues as far as I can tell. Once the RTTI issue wasn't
an issue, we were looking for a way to properly track weak pointers to objects
to solve some of the threading issues we have been running into which naturally
led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared
pointer from just a pointer, which is also easily solved using the
std::tr1::enable_shared_from_this class.
The main reason for this move back is so we can start properly having weak
references to objects. Currently a lldb_private::Thread class has a refrence
to its parent lldb_private::Process. This doesn't work well when we now hand
out a SBThread object that contains a shared pointer to a lldb_private::Thread
as this SBThread can be held onto by external clients and if they end up
using one of these objects we can easily crash.
So the next task is to start adopting std::tr1::weak_ptr where ever it makes
sense which we can do with lldb_private::Debugger, lldb_private::Target,
lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and
many more objects now that they are no longer using intrusive ref counted
pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive
pointers).
llvm-svn: 149207
Fixed an ARM backtracing issue where if the previous frame was a thumb
function and it was a tail call so that the current frame returned to
an address that would fall into the next function, we would use the
next function as the basis for how we unwound the previous frame's
registers and of course get things wrong. We now fix the PC code
address using the current ABI plug-in, and the ARM ABI plug-in has
been modified to correctly fix the code address. So when we do the
symbol context lookup, instead of taking an address like 0x1001 and
decrementing 1, and looking up the symbol context for a frame, we
now correctly fix 0x1001 to 0x1000, then decrement that by 1 to
get the correct symbol context.
I added a bunch more logging to "log enable lldb uwnind" to help
us in the future. We now log the PC, FP and SP (if they are available),
and we also dump the "active_row" that we find for unwinding a frame.
llvm-svn: 147747
Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject
which is much more convenient.
Return the "return value object" as a persistent variable if requested.
llvm-svn: 147157
1 -- an address pointing off into non-executable memory -- don't
abort the unwind. We'll use the ABI's default UnwindPlan to try
to get out of frame 1 and on many platforms with a standard frame
chain stack layout we can get back on track and get a valid frame
2. This preserves the lldb behavior to-date; the change last week
to require the memory region to be executable broke it.
I'd like to mark this frame specially when displayed to the user;
I tried to override the places where the frame's pc value is returned
to change it to a sentinel value (e.g. LLDB_INVALID_ADDRESS) but
couldn't get that to work cleanly so I backed that part out for
now. When this happens we'll often miss one of the user's actual
frames, the one that's of most interest to the user, so I'd like
to make this visually distinctive.
Note that a frame in non-executable memory region is only allowed
for frame 1. After that we should be solid on the unwind and any
pc address in non-executable memory indicates a failure and we
should stop unwinding.
llvm-svn: 146723
dispatch functions that are implemented in hand-written assembly.
There is also hand-written eh_frame instructions for unwinding
from these functions.
Normally we don't use eh_frame instructions for the currently
executing function, prefering the assembly instruction profiling
method. But in these hand-written dispatch functions, the
profiling is doomed and we should use the eh_frame instructions.
Unfortunately there's no easy way to flag/extend the eh_frame/debug_frame
sections to annotate if the unwind instructions are accurate at
all addresses ("asynchronous") or if they are only accurate at locations
that can throw an exception ("synchronous" and the normal case for
gcc/clang generated eh_frame/debug_frame CFI).
<rdar://problem/10508134>
llvm-svn: 146551
Check that the pc value for frames up the stack is in a
mapped+executable region of memory.
Check that the stack pointer for frames up the stack is
in a mapped+readable region of memory.
If the unwinder ever makes a mistake walking the stack,
these checks will help to keep it from going too far into
the weeds.
These aren't fixing any bugs that I know of, but they
add extra robustness to a complicated task.
llvm-svn: 146478
if this is a mapped/executable region of memory. If it isn't, we've jumped
through a bad pointer and we know how to unwind the stack correctly based
on the ABI.
Previously I had 0x0 special cased but if you jumped to 0x2 on x86_64 one
frame would be skipped because the unwinder would try using the x86_64
ArchDefaultUnwindPlan which relied on the rbp.
Fixes <rdar://problem/10508291>
llvm-svn: 146477
- If you download and build the sources in the Xcode project, x86_64 builds
by default using the "llvm.zip" checkpointed LLVM.
- If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the
Xcode project will download the right LLVM sources and build them from
scratch
- If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib"
directory, we will use the sources you have placed in the LLDB directory.
Python can now be disabled for platforms that don't support it.
Changed the way the libllvmclang.a files get used. They now all get built into
arch specific directories and never get merged into universal binaries as this
was causing issues where you would have to go and delete the file if you wanted
to build an extra architecture slice.
llvm-svn: 143678
RegisterContextLLDBs it contains.
Previously RegisterContextLLDB objects had a pointer to their "next"
frame down the stack. e.g. stack starts at frame 0; frame 3 has a
pointer to frame 2. This is used to retreive callee saved register
values. When debugging an inferior that has blown out its own stack,
however, this could result in lldb blowing out its own stack while
recursing down to retrieve register values.
RegisterContextLLDB no longer has a pointer to its next frame; it
has a reference to the UnwindLLDB which contains it. When it needs
to retrieve a reg value, it asks the UnwindLLDB for that reg value
and UnwindLLDB iterates through the frames until it finds a location.
llvm-svn: 143423
"object borked"... Also made the error when the checker fails reflect this fact rather than
report a crash at 0x0.
Also a little cleanup:
- StopInfoMachException had a redundant copy of the description string.
- ThreadPlanCallFunction had a redundant copy of the thread, and had a
copy of the process that it didn't really need.
llvm-svn: 143419
with the same CFA (or an alternating sequence between two CFA values) to catch a handful of
unwind cases where lldb will inf loop trying to unwind a stack.
llvm-svn: 142331
a watchpoint for either the variable encapsulated by SBValue (Watch) or the pointee
encapsulated by SBValue (WatchPointee).
Removed SBFrame::WatchValue() and SBFrame::WatchLocation() API as a result of that.
Modified the watchpoint related test suite to reflect the change.
Plus replacing WatchpointLocation with Watchpoint throughout the code base.
There are still cleanups to be dome. This patch passes the whole test suite.
Check it in so that we aggressively catch regressions.
llvm-svn: 141925
iterate on the available watchpoint locations and to perform watchpoint manipulations.
I still need to export the SBWatchpointLocation class as well as the added watchpoint
manipulation methods to the Python interface. And write test cases for them.
llvm-svn: 140575
data sent back to the debugger. On the debugger side, use the opportunity during the
StopInfoMachException::CreateStopReasonWithMachException() method to set the hardware index
for the very watchpoint location.
llvm-svn: 139975
the arm emulate instruction unwinder so you can leave it
on by default and not be overwhelmed. Set verbose mode to
get the full story on how the unwindplans were created.
llvm-svn: 139897
UnwindPlan for unwinding from the first instruction of an otherwise
unknown function call (GetUnwindPlanArchitectureDefaultAtFunctionEntry()).
Update RegisterContextLLDB::GetFullUnwindPlanForFrame() to detect the
case of a frame 0 at address 0x0 which indicates that we jumped through
a NULL function pointer. Use the ABI's FunctionEntryUnwindPlan to
find the caller frame.
These changes make it so lldb can identify the calling frame correctly
in code like
int main ()
{
void (*f)(void) = 0;
f();
}
llvm-svn: 139760
register names when dumping variable locations and location lists. Also did
some cleanup where "int" types were being used for "lldb::RegisterKind"
values.
llvm-svn: 138988
plug-ins are add on plug-ins for the lldb_private::Process class that can add
thread contexts that are read from memory. It is common in kernels to have
a lot of threads that are not currently executing on any cores (JTAG debugging
also follows this sort of thing) and are context switched out whose state is
stored in memory data structures. Clients can now subclass the OperatingSystem
plug-ins and then make sure their Create functions correcltly only enable
themselves when the right binary/target triple are being debugged. The
operating system plug-ins get a chance to attach themselves to processes just
after launching or attaching and are given a lldb_private::Process object
pointer which can be inspected to see if the main executable, target triple,
or any shared libraries match a case where the OS plug-in should be used.
Currently the OS plug-ins can create new threads, define the register contexts
for these threads (which can all be different if desired), and populate and
manage the thread info (stop reason, registers in the register context) as
the debug session goes on.
llvm-svn: 138228
- reorganizing the PTS (Partial Template Specializations) in FormatManager.h
- applied a patch by Filipe Cabecinhas to make LLDB compile with GCC
Functional changes:
- fixed an issue where command type summary add for type "struct Foo" would not match any types.
currently, "struct" will be stripped off and type "Foo" will be matched.
similar behavior occurs for class, enum and union specifiers.
llvm-svn: 138020
an executable file if it is right next to a dSYM file that is found using
DebugSymbols. The code also looks into a bundle if the dSYM file is right
next to a bundle.
Modified the MacOSX kernel dynamic loader plug-in to correctly set the load
address for kext sections. This is a tad tricky because of how LLDB chooses
to treat mach-o segments with no name. Also modified the loader to properly
handle the older version 1 kext summary info.
Fixed a crasher in the Mach-o object file parser when it is trying to set
the section size correctly for dSYM sections.
Added packet dumpers to the CommunicationKDP class. We now also properly
detect address byte sizes based on the cpu type and subtype that is provided.
Added a read memory and read register support to CommunicationKDP. Added a
ThreadKDP class that now uses subclasses of the RegisterContextDarwin_XXX for
arm, i386 and x86_64.
Fixed some register numbering issues in the RegisterContextDarwin_arm class
and added ARM GDB numbers to the ARM_GCC_Registers.h file.
Change the RegisterContextMach_XXX classes over to subclassing their
RegisterContextDarwin_XXX counterparts so we can share the mach register
contexts between the user and kernel plug-ins.
llvm-svn: 135466
darwin (not sure about other platforms).
Modified the communication and connection classes to not require the
BytesAvailable function. Now the "Read(...)" function has a timeout in
microseconds.
Fixed a lot of assertions that were firing off in certain cases and replaced
them with error output and code that can deal with the assertion case.
llvm-svn: 133224
virtual bool
ABI::StackUsesFrames () = 0;
Should return true if your ABI uses frames when doing stack backtraces. This
means a frame pointer is used that points to the previous stack frame in some
way or another.
virtual bool
ABI::CallFrameAddressIsValid (lldb::addr_t cfa) = 0;
Should take a look at a call frame address (CFA) which is just the stack
pointer value upon entry to a function. ABIs usually impose alignment
restrictions (4, 8 or 16 byte aligned), and zero is usually not allowed.
This function should return true if "cfa" is valid call frame address for
the ABI, and false otherwise. This is used by the generic stack frame unwinding
code to help determine when a stack ends.
virtual bool
ABI::CodeAddressIsValid (lldb::addr_t pc) = 0;
Validates a possible PC value and returns true if an opcode can be at "pc".
Some ABIs or architectures have fixed width instructions and must be aligned
to a 2 or 4 byte boundary. "pc" can be an opcode or a callable address which
means the load address might be decorated with extra bits (such as bit zero
to indicate a thumb function call for ARM targets), so take this into account
when returning true or false. The address should also be validated to ensure
it is a valid address for the address size of the inferior process. 32 bit
targets should make sure the address is less than UINT32_MAX.
Modified UnwindLLDB to use the new ABI functions to help it properly terminate
stacks.
Modified the mach-o function that extracts dependent files to not resolve the
path as the paths inside a binary might not match those on the current
host system.
llvm-svn: 132021
parse NOP instructions. I added the new table entries for the NOP for the
plain NOP, Yield, WFE, WFI, and SEV variants. Modified the opcode emulation
function EmulateInstructionARM::EmulateMOVRdSP(...) to notify us when it is
creating a frame. Also added an abtract way to detect the frame pointer
register for both the standard ARM ABI and for Darwin.
Fixed GDBRemoteRegisterContext::WriteAllRegisterValues(...) to correctly be
able to individually write register values back if case the 'G' packet is
not implemented or returns an error.
Modified the StopInfoMachException to "trace" stop reasons. On ARM we currently
use the BVR/BCR register pairs to say "stop when the PC is not equal to the
current PC value", and this results in a EXC_BREAKPOINT mach exception that
has 0x102 in the code.
Modified debugserver to create the short option string from long option
definitions to make sure it doesn't get out of date. The short option string
was missing many of the newer short option values due to a modification of
the long options defs, and not modifying the short option string.
llvm-svn: 131911
bool
Address::SetLoadAddress (lldb::addr_t load_addr, Target *target);
Added an == and != operator to RegisterValue.
Modified the ThreadPlanTracer to use RegisterValue objects to store the
register values when single stepping. Also modified the output to be a bit
less wide.
Fixed the ABIMacOSX_arm to not overwrite stuff on the stack. Also made the
trivial function call be able to set the ARM/Thumbness of the target
correctly, and also sets the return value ARM/Thumbness.
Fixed the encoding on the arm s0-s31 and d16 - d31 registers when the default
register set from a standard GDB server register sets.
llvm-svn: 131517
respective ABI plugins as they were plug-ins that supplied ABI specfic info.
Also hookep up the UnwindAssemblyInstEmulation so that it can generate the
unwind plans for ARM.
Changed the way ABI plug-ins are handed out when you get an instance from
the plug-in manager. They used to return pointers that would be mananged
individually by each client that requested them, but now they are handed out
as shared pointers since there is no state in the ABI objects, they can be
shared.
llvm-svn: 131193
into some cleanup I have been wanting to do when reading/writing registers.
Previously all RegisterContext subclasses would need to implement:
virtual bool
ReadRegisterBytes (uint32_t reg, DataExtractor &data);
virtual bool
WriteRegisterBytes (uint32_t reg, DataExtractor &data, uint32_t data_offset = 0);
There is now a new class specifically designed to hold register values:
lldb_private::RegisterValue
The new register context calls that subclasses must implement are:
virtual bool
ReadRegister (const RegisterInfo *reg_info, RegisterValue ®_value) = 0;
virtual bool
WriteRegister (const RegisterInfo *reg_info, const RegisterValue ®_value) = 0;
The RegisterValue class must be big enough to handle any register value. The
class contains an enumeration for the value type, and then a union for the
data value. Any integer/float values are stored directly in an appropriate
host integer/float. Anything bigger is stored in a byte buffer that has a length
and byte order. The RegisterValue class also knows how to copy register value
bytes into in a buffer with a specified byte order which can be used to write
the register value down into memory, and this does the right thing when not
all bytes from the register values are needed (getting a uint8 from a uint32
register value..).
All RegiterContext and other sources have been switched over to using the new
regiter value class.
llvm-svn: 131096
are defined as enumerations. Current bits include:
eEmulateInstructionOptionAutoAdvancePC
eEmulateInstructionOptionIgnoreConditions
Modified the EmulateInstruction class to have a few more pure virtuals that
can help clients understand how many instructions the emulator can handle:
virtual bool
SupportsEmulatingIntructionsOfType (InstructionType inst_type) = 0;
Where instruction types are defined as:
//------------------------------------------------------------------
/// Instruction types
//------------------------------------------------------------------
typedef enum InstructionType
{
eInstructionTypeAny, // Support for any instructions at all (at least one)
eInstructionTypePrologueEpilogue, // All prologue and epilogue instructons that push and pop register values and modify sp/fp
eInstructionTypePCModifying, // Any instruction that modifies the program counter/instruction pointer
eInstructionTypeAll // All instructions of any kind
} InstructionType;
This allows use to tell what an emulator can do and also allows us to request
these abilities when we are finding the plug-in interface.
Added the ability for an EmulateInstruction class to get the register names
for any registers that are part of the emulation. This helps with being able
to dump and log effectively.
The UnwindAssembly class now stores the architecture it was created with in
case it is needed later in the unwinding process.
Added a function that can tell us DWARF register names for ARM that goes
along with the source/Utility/ARM_DWARF_Registers.h file:
source/Utility/ARM_DWARF_Registers.c
Took some of plug-ins out of the lldb_private namespace.
llvm-svn: 130189
inline contexts when the deepest most block is not inlined.
Added source path remappings to the lldb_private::Target class that allow it
to remap paths found in debug info so we can find source files that are elsewhere
on the current system.
Fixed disassembly by function name to disassemble inline functions that are
inside other functions much better and to show enough context before the
disassembly output so you can tell where things came from.
Added the ability to get more than one address range from a SymbolContext
class for the case where a block or function has discontiguous address ranges.
llvm-svn: 130044
class now implements the Host functionality for a lot of things that make
sense by default so that subclasses can check:
int
PlatformSubclass::Foo ()
{
if (IsHost())
return Platform::Foo (); // Let the platform base class do the host specific stuff
// Platform subclass specific code...
int result = ...
return result;
}
Added new functions to the platform:
virtual const char *Platform::GetUserName (uint32_t uid);
virtual const char *Platform::GetGroupName (uint32_t gid);
The user and group names are cached locally so that remote platforms can avoid
sending packets multiple times to resolve this information.
Added the parent process ID to the ProcessInfo class.
Added a new ProcessInfoMatch class which helps us to match processes up
and changed the Host layer over to using this new class. The new class allows
us to search for processs:
1 - by name (equal to, starts with, ends with, contains, and regex)
2 - by pid
3 - And further check for parent pid == value, uid == value, gid == value,
euid == value, egid == value, arch == value, parent == value.
This is all hookup up to the "platform process list" command which required
adding dumping routines to dump process information. If the Host class
implements the process lookup routines, you can now lists processes on
your local machine:
machine1.foo.com % lldb
(lldb) platform process list
PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME
====== ====== ========== ========== ========== ========== ======================== ============================
99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge
94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker
94852 244 username usergroup username usergroup x86_64-apple-darwin Safari
94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode
92742 92710 username usergroup username usergroup i386-apple-darwin debugserver
This of course also works remotely with the lldb-platform:
machine1.foo.com % lldb-platform --listen 1234
machine2.foo.com % lldb
(lldb) platform create remote-macosx
Platform: remote-macosx
Connected: no
(lldb) platform connect connect://localhost:1444
Platform: remote-macosx
Triple: x86_64-apple-darwin
OS Version: 10.6.7 (10J869)
Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386
Hostname: machine1.foo.com
Connected: yes
(lldb) platform process list
PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME
====== ====== ========== ========== ========== ========== ======================== ============================
99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation
99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb
99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge
94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker
94852 244 username usergroup username usergroup x86_64-apple-darwin Safari
The lldb-platform implements everything with the Host:: layer, so this should
"just work" for linux. I will probably be adding more stuff to the Host layer
for launching processes and attaching to processes so that this support should
eventually just work as well.
Modified the target to be able to be created with an architecture that differs
from the main executable. This is needed for iOS debugging since we can have
an "armv6" binary which can run on an "armv7" machine, so we want to be able
to do:
% lldb
(lldb) platform create remote-ios
(lldb) file --arch armv7 a.out
Where "a.out" is an armv6 executable. The platform then can correctly decide
to open all "armv7" images for all dependent shared libraries.
Modified the disassembly to show the current PC value. Example output:
(lldb) disassemble --frame
a.out`main:
0x1eb7: pushl %ebp
0x1eb8: movl %esp, %ebp
0x1eba: pushl %ebx
0x1ebb: subl $20, %esp
0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18
0x1ec3: popl %ebx
-> 0x1ec4: calll 0x1f12 ; getpid
0x1ec9: movl %eax, 4(%esp)
0x1ecd: leal 199(%ebx), %eax
0x1ed3: movl %eax, (%esp)
0x1ed6: calll 0x1f18 ; printf
0x1edb: leal 213(%ebx), %eax
0x1ee1: movl %eax, (%esp)
0x1ee4: calll 0x1f1e ; puts
0x1ee9: calll 0x1f0c ; getchar
0x1eee: movl $20, (%esp)
0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6
0x1efa: movl $12, %eax
0x1eff: addl $20, %esp
0x1f02: popl %ebx
0x1f03: leave
0x1f04: ret
This can be handy when dealing with the new --line options that was recently
added:
(lldb) disassemble --line
a.out`main + 13 at test.c:19
18 {
-> 19 printf("Process: %i\n\n", getpid());
20 puts("Press any key to continue..."); getchar();
-> 0x1ec4: calll 0x1f12 ; getpid
0x1ec9: movl %eax, 4(%esp)
0x1ecd: leal 199(%ebx), %eax
0x1ed3: movl %eax, (%esp)
0x1ed6: calll 0x1f18 ; printf
Modified the ModuleList to have a lookup based solely on a UUID. Since the
UUID is typically the MD5 checksum of a binary image, there is no need
to give the path and architecture when searching for a pre-existing
image in an image list.
Now that we support remote debugging a bit better, our lldb_private::Module
needs to be able to track what the original path for file was as the platform
knows it, as well as where the file is locally. The module has the two
following functions to retrieve both paths:
const FileSpec &Module::GetFileSpec () const;
const FileSpec &Module::GetPlatformFileSpec () const;
llvm-svn: 128563
public types and public enums. This was done to keep the SWIG stuff from
parsing all sorts of enums and types that weren't needed, and allows us to
abstract our API better.
llvm-svn: 128239
static archive that can be linked against. LLDB.framework/lldb.so
exports a very controlled API. Splitting the API into a static
library allows other tools (debugserver for now) to use the power
of the LLDB debugger core, yet not export it as its API is not
portable or maintainable. The Host layer and many of the other
internal only APIs can now be statically linked against.
Now LLDB.framework/lldb.so links against "liblldb-core.a" instead
of compiling the .o files only for the shared library. This fix
is only for compiling with Xcode as the Makefile based build already
does this.
The Xcode projecdt compiler has been changed to LLVM. Anyone using
Xcode 3 will need to manually change the compiler back to GCC 4.2,
or update to Xcode 4.
llvm-svn: 127963
an interface to a local or remote debugging platform. By default each host OS
that supports LLDB should be registering a "default" platform that will be
used unless a new platform is selected. Platforms are responsible for things
such as:
- getting process information by name or by processs ID
- finding platform files. This is useful for remote debugging where there is
an SDK with files that might already or need to be cached for debug access.
- getting a list of platform supported architectures in the exact order they
should be selected. This helps the native x86 platform on MacOSX select the
correct x86_64/i386 slice from universal binaries.
- Connect to remote platforms for remote debugging
- Resolving an executable including finding an executable inside platform
specific bundles (macosx uses .app bundles that contain files) and also
selecting the appropriate slice of universal files for a given platform.
So by default there is always a local platform, but remote platforms can be
connected to. I will soon be adding a new "platform" command that will support
the following commands:
(lldb) platform connect --name machine1 macosx connect://host:port
Connected to "machine1" platform.
(lldb) platform disconnect macosx
This allows LLDB to be well setup to do remote debugging and also once
connected process listing and finding for things like:
(lldb) process attach --name x<TAB>
The currently selected platform plug-in can now auto complete any available
processes that start with "x". The responsibilities for the platform plug-in
will soon grow and expand.
llvm-svn: 127286
of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up
doing was:
- Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics
the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple
to give us the machine type from llvm::Triple::ArchType.
- There is a new ArchSpec::Core definition which further qualifies the CPU
core we are dealing with into a single enumeration. If you need support for
a new Core and want to debug it in LLDB, it must be added to this list. In
the future we can allow for dynamic core registration, but for now it is
hard coded.
- The ArchSpec can now be initialized with a llvm::Triple or with a C string
that represents the triple (it can just be an arch still like "i386").
- The ArchSpec can still initialize itself with a architecture type -- mach-o
with cpu type and subtype, or ELF with e_machine + e_flags -- and this will
then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core.
The mach-o cpu type and subtype can be accessed using the getter functions:
uint32_t
ArchSpec::GetMachOCPUType () const;
uint32_t
ArchSpec::GetMachOCPUSubType () const;
But these functions are just converting out internal llvm::Triple::ArchSpec
+ ArchSpec::Core back into mach-o. Same goes for ELF.
All code has been updated to deal with the changes.
This should abstract us until later when the llvm::TargetSpec stuff gets
finalized and we can then adopt it.
llvm-svn: 126278
Turns out that they can be funneled through the helper methods
EmulateShiftImm()/ EmulateShiftReg() as well.
Modify EmulateShiftImm() to handle SRType_ROR and SRType_RRX.
And fix a typo in the impl of utility Shift_C() in ARMUtils.h.
llvm-svn: 125689
Create two helper methods EmulateShiftImm() and EmulateShiftReg() and have ASR, LSL, and LSR
delegate to the helper methods which take an extra ARM_ShifterType parameter.
The opcodes tables have not been updated yet to reflect these new entries.
llvm-svn: 125633
ArchDefaultUnwindPlan plug-in interfaces are now cached per architecture
instead of being leaked for every frame.
Split the ArchDefaultUnwindPlan_x86 into ArchDefaultUnwindPlan_x86_64 and
ArchDefaultUnwindPlan_i386 interfaces.
There were sporadic crashes that were due to something leaking or being
destroyed when doing stack crawls. This patch should clear up these issues.
llvm-svn: 125541
an imm12 into imm32 for ARM or Thumb so that they now handle carry_in/carry_out.
Funnel ARMExpandImm()/ThumbExpandImm() to the enhanced ARMExpandImm_C()/ThumbExpandImm_C()
functions.
llvm-svn: 125508
module's AST context. Prior to this fix, with gcc binaries, we end up with
a full class definition for any used classes in each compile unit due to the
one definition rule. This would result in us making N copies of class T, where
N is the number of compile units that use class T, in the module AST. When
an expression would then try and use any types that were duplicated, it would
quickly confuse clang and make expression evaluation fail due to all of the
duplicate types that got copied over. This is now fixed by making a map of
types in the DWARF that maps type names to a collection of types + declaration
(file + line number) + DIE. Then later when we find a type we look in this
module map and find any already cached types that we can just use.
8935777
llvm-svn: 125207
to be fed 4 callbacks: read/write memory, and read/write registers. After this,
you can tell the object to read an instruction. This will cause the class to read
the PC, and read and instruction. Then you can emulate the instruction by calling
EvaluateInstruction. This will cause the class to figure out exactly what an opcode
does, and call the read/write mem/regs functions with actual values which allows one
to emulate an instruction without running a process, or it allows one to watch the
context information (the memory write is a pushing register 3 onto the stack at offset
12) so it can be used for generating call frame information. This way, in the future,
we will have one class that can be used to emulate instructions and generate our
unwind info from assembly.
llvm-svn: 123998
bool RegisterContextLLDB::GetPC (addr_t& pc);
to:
bool RegisterContextLLDB::ReadPC (addr_t& pc);
To avoid confusion with the GetPC() function that is part of the
lldb_private::RegisterContext:
uint64_t RegisterContext::GetPC (uint64_t fail_value);
Bad things could happen if the two got intermixed and the wrong one got
called.
Fixed inifinite loop detection by watching for two frames where the
RegisterContextLLDB::CursorSP contains the same start_pc and cfa.
llvm-svn: 123673
a method:
void RegisterContext::InvalidateIfNeeded (bool force);
Each time this function is called, when "force" is false, it will only call
the pure virtual "virtual void RegisterContext::InvalideAllRegisters()" if
the register context's stop ID doesn't match that of the process. When the
stop ID doesn't match, or "force" is true, the base class will clear its
cached registers and the RegisterContext will update its stop ID to match
that of the process. This helps make it easier to correctly flush the register
context (possibly from multiple locations depending on when and where new
registers are availabe) without inadvertently clearing the register cache
when it doesn't need to be.
Modified the ProcessGDBRemote plug-in to be much more efficient when it comes
to:
- caching the expedited registers in the stop reply packets (we were ignoring
these before and it was causing us to read at least three registers every
time we stopped that were already supplied in the stop reply packet).
- When a thread has no stop reason, don't keep asking for the thread stopped
info. Prior to this fix we would continually send a qThreadStopInfo packet
over and over when any thread stop info was requested. We now note the stop
ID that the stop info was requested for and avoid multiple requests.
Cleaned up some of the expression code to not look for ClangExpressionVariable
objects up by name since they are now shared pointers and we can just look for
the exact pointer match and avoid possible errors.
Fixed an bug in the ValueObject code that would cause children to not be
displayed.
llvm-svn: 123127
frames, UnwindLLDB could create the incorrect RegisterContext for a given
stack frame because it was using the frame index (not the concrete frame
index). This was causing crashes when doing backtraces through the
SBFrame::GetFP() because a NULL register context was being returned for the
deepest stack frame.
llvm-svn: 123052
subclasses will automatically be able to take advantage of caching. The
cache line size is set to 512 by default.
This greatly speeds up stack backtraces on MacOSX when using the
ProcessGDBRemote process plug-in since only about 6300 packets per second
can be sent.
Initial speedups show:
Prior to caching: 10,000 stack frames took 5.2 seconds
After caching: 10,000 stack frames in 240 ms!
About a 20x speedup!
llvm-svn: 122996
cache even when a valid process exists. Previously, Target::ReadMemory would
read from the process if there was a valid one and then fallback to the
object file cache.
llvm-svn: 122989
an issue with the way the UnwindLLDB was handing out RegisterContexts: it
was making shared pointers to register contexts and then handing out just
the pointers (which would get put into shared pointers in the thread and
stack frame classes) and cause double free issues. MallocScribble helped to
find these issues after I did some other cleanup. To help avoid any
RegisterContext issue in the future, all code that deals with them now
returns shared pointers to the register contexts so we don't end up with
multiple deletions. Also now that the RegisterContext class doesn't require
a stack frame, we patched a memory leak where a StackFrame object was being
created and leaked.
Made the RegisterContext class not have a pointer to a StackFrame object as
one register context class can be used for N inlined stack frames so there is
not a 1 - 1 mapping. Updates the ExecutionContextScope part of the
RegisterContext class to never return a stack frame to indicate this when it
is asked to recreate the execution context. Now register contexts point to the
concrete frame using a concrete frame index. Concrete frames are all of the
frames that are actually formed on the stack of a thread. These concrete frames
can be turned into one or more user visible frames due to inlining. Each
inlined stack frame has the exact same register context (shared via shared
pointers) as any parent inlined stack frames all the way up to the concrete
frame itself.
So now the stack frames and the register contexts should behave much better.
llvm-svn: 122976
0 mid-stack, stop backtracing.
SectionLoadList.cpp (ResolveLoadAddress): Don't assert on an
out-of-range address, just return an invalid Address object.
The unwinder may be passing in invalid addresses on the final
stack frame and the assert is a problem.
llvm-svn: 122386
RegisterContext* - normally this is retrieved from the ExecutionContext's
StackFrame but when we need to evaluate an expression while creating
the stack frame list this can be a little tricky.
Add DW_OP_deref_size, needed for the _sigtramp FDE expression.
Add support for processing DWARF expressions in RegisterContextLLDB.
Update callers to DWARFExpression::Evaluate.
llvm-svn: 119885
we're using the stack pointer to define the CFA again. Makes unwinds
while sitting at the 'ret' instruction work, assuming we have accurate
function address bounds.
llvm-svn: 119327
needs to use the current pc and current offset in two ways: To
determine which function we are currently executing, and the decide
how much of that function has executed so far. For the former use,
we need to back up the saved pc value by one byte if we're going to
use the correct function's unwind information -- we may be executing
a CALL instruction at the end of a function and the following instruction
belongs to a new function, or we may be looking at unwind information
which only covers the call instruction and not the subsequent instruction.
But when we're talking about deciding which row of an UnwindPlan to
execute, we want to use the actual byte offset in the function, not the
byte offset - 1.
Right now RegisterContextLLDB is tracking both the "real" offset and
an "offset minus one" and different parts of the class have to know
which one to use and they need to be updated/set in tandem. I want
to revisit this at some point.
The second change made in looking up eh_frame information; it was
formerly done by looking for the start address of the function we
are currently executing. But it is possible to have unwind information
for a function which only covers a small section of the function's
address range. In which case looking up by the start pc value may not
find the eh_frame FDE.
The hand-written _sigtramp() unwind info on Mac OS X, which covers
exactly one instruction in the middle of the function, happens to
trigger both of these issues.
I still need to get the UnwindPlan runner to handle arbitrary dwarf
expressions in the FDE but there's a good chance it will be easy to
reuse the DWARFExpression class to do this.
llvm-svn: 118882
I only did a tiny bit of testing; in the one case I tried changing the
contents of a radar in the middle of a stack and it was still current in
the live register context so it filtered down to frame 0 and was handed
over to the live register set RegisterContext. I need to test a case
where a register is saved on the stack in memory before I check this
one off.
llvm-svn: 118486
the frame count is requested or each frame is individually requested.
In practice this doesn't seem to help anything because we have
functions like StackFrameList::GetNumFrames() which is going to
request each frame anyway. And classes like ThreadPlanStepRange
and ThreadPlanStepOverRange get the stack depth in their ctor forcing
a full stack walk. But at least UnwindLLDB will delay doing a full
walk if it can.
llvm-svn: 118477
FuncUnwinders object if the eh_frame section was missing
from an objfile. Worked fine on x86_64 but on i386 where
eh_frame is unusual, that resulted in the arch default
UnwindPlan being used all the time instead of picking up
an assembly profile based unwindplan.
llvm-svn: 118467
don't crash if we disable logging when some code already has a copy of the
logger. Prior to this fix, logs were handed out as pointers and if they were
held onto while a log got disabled, then it could cause a crash. Now all logs
are handed out as shared pointers so this problem shouldn't happen anymore.
We are also using our new shared pointers that put the shared pointer count
and the object into the same allocation for a tad better performance.
llvm-svn: 118319
fixed them. Added DISALLOW_COPY_AND_ASSIGN to classes that should
not be bitwise copied. Added default initializers for member
variables that weren't being initialized in the ctor. Fixed a few
shadowed local variable mistakes.
llvm-svn: 118240
RegisterContextLLDB holds a reference to the SymbolContext
in the vector of Cursors that UnwindLLDB maintains. Switch
UnwindLLDB to hold a vector of shared pointers of Cursors
so this reference doesn't become invalid.
Correctly falling back from the "fast" UnwindPlan to the
"full" UnwindPlan when additional registers need to be
retrieved.
llvm-svn: 118218
loaded/parsed. Should add timers to this eventually.
Delay getting a full UnwindPlan if it's possible to unwind with
just a fast UnwindPlan. This keeps us from reading the eh_frame
section unless we hit something built -fomit-frame pointer or we
hit a frame with no symbol (read: no start address) available.
It doesn't look like it is correctly falling back to using the
full UnwindPlan to provide additional registers that the fast
UnwindPlan doesn't supply; e.g. go to the middle of a stack and
ask for r12 and it will show you the value of r12 in frame 0.
That's a bug for tomorrow.
llvm-svn: 117361
gets to be a problem if you have a unbounded stack walk.
Fix the CFA sanity checks. Add one to the arch default UnwindPlan run which was giving
one extra stack frame on the main thread. Fix a couple of logging lines that had their
argument order incorrect.
llvm-svn: 117350
prologue profiling.
Change the log print statements to elide the thread number, make
some of them only print when IsLogVerbose().
Add a couple of sanity checks for impossible CFA values so backtraces
don't go too far off into the weeds.
llvm-svn: 117343
Not yet enabled as the default unwinder but there are no known
backtrace problems with the code at this point.
Added 'log enable lldb unwind' to help diagnose backtrace problems;
this output needs a little refining but it's a good first step.
eh_frame information is currently read unconditionally - the code
is structured to allow this to be delayed until it's actually needed.
There is a performance hit when you have to parse the eh_frame
information for any largeish executable/library so it's necessary
to avoid if possible.
It's confusing having both the UnwindPlan::RegisterLocation struct
and the RegisterConextLLDB::RegisterLocation struct, I need to rename
one of them.
The writing of registers isn't done in the RegisterConextLLDB subclass
yet; neither is the running of complex DWARF expressions from eh_frame
(e.g. used for _sigtramp on Mac OS X).
llvm-svn: 117256
whether a given register number is treated as volatile
or not for a given architecture/platform.
approx 450 lines of boilerplate, 50 lines of actual code. :)
llvm-svn: 114537
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
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
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
This will allow debugger plug-ins to make any instance of "lldb_private::StopInfo"
that can completely describe any stop reason. It also provides a framework for
doing intelligent things with the stop info at important times in the lifetime
of the inferior.
Examples include the signal stop info in StopInfoUnixSignal. It will check with
the process to see that the current action is for the signal. These actions
include wether to stop for the signal, wether the notify that the signal was
hit, and wether to pass the signal along to the inferior process. The
StopInfoUnixSignal class overrides the "ShouldStop()" method of StopInfo and
this allows the stop info to determine if it should stop at the signal or
continue the process.
StopInfo subclasses must override the following functions:
virtual lldb::StopReason
GetStopReason () const = 0;
virtual const char *
GetDescription () = 0;
StopInfo subclasses can override the following functions:
// If the subclass returns "false", the inferior will resume. The default
// version of this function returns "true" which means the default stop
// info will stop the process. The breakpoint subclass will check if
// the breakpoint wants us to stop by calling any installed callback on
// the breakpoint, and also checking if the breakpoint is for the current
// thread. Signals will check if they should stop based off of the
// UnixSignal settings in the process.
virtual bool
ShouldStop (Event *event_ptr);
// Sublasses can state if they want to notify the debugger when "ShouldStop"
// returns false. This would be handy for breakpoints where you want to
// log information and continue and is also used by the signal stop info
// to notify that a signal was received (after it checks with the process
// signal settings).
virtual bool
ShouldNotify (Event *event_ptr)
{
return false;
}
// Allow subclasses to do something intelligent right before we resume.
// The signal class will figure out if the signal should be propagated
// to the inferior process and pass that along to the debugger plug-ins.
virtual void
WillResume (lldb::StateType resume_state)
{
// By default, don't do anything
}
The support the Mach exceptions was moved into the lldb/source/Plugins/Process/Utility
folder and now doesn't polute the lldb_private::Thread class with platform
specific code.
llvm-svn: 110184
enabled LLVM make style building and made this compile LLDB on Mac OS X. We
can now iterate on this to make the build work on both linux and macosx.
llvm-svn: 108009
type and sub-type, or an ELF e_machine value. Also added a generic CPU type
to the arch spec class so we can have a single arch definition that the LLDB
core code can use. Previously a lot of places in the code were using the
mach-o definitions from a macosx header file.
Switches over to using "llvm/Support/MachO.h" for the llvm::MachO::XXX for the
CPU types and sub types for mach-o ArchSpecs. Added "llvm/Support/ELF.h" so
we can use the "llvm::ELF::XXX" defines for the ELF ArchSpecs.
Got rid of all CPU_TYPE_ and CPU_SUBTYPE_ defines that were previously being
used in LLDB.
llvm-svn: 105806
Greg Clayton