History log of /external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
d2d164e5906a7740de680e8e49b41d3b31c4dba8 19-Jul-2013 Jason Molenda <jmolenda@apple.com> Don't use a function-scope static varaibles in
RegisterContextLLDB::SavedLocationForRegister to cache the pc and
sp register numbers -- if lldb is debugging multiple Targets of
different architectures, this will be incorrect. If these were
to be cached anywhere, it would have to be up in the Target.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@186651 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
4f33a8216d66ac3934d87972596b43bb13aeb2c2 18-Jul-2013 Ashok Thirumurthi <ashok.thirumurthi@intel.com> Fix the partial backtrace when using a combination of stripped function symbols
and -fomit-frame-pointer.

- Parses eh_frame FDEs to determine the function address and size so that
the call frame parsing can continue.

Note: This code path is specific to ELF and PECOFF, because ObjectFileMachO
uses LCT_FunctionStarts to efficiently populate the symbol table.

Thanks to Jason Molenda for the review!


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@186585 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
52f792329be5db8e38961350589e97e8f2823acd 12-Jul-2013 Greg Clayton <gclayton@apple.com> Huge change to clean up types.

A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.

This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@186130 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
8c9353a33ddb708ffbfc569e3799831833f181b5 05-Jun-2013 Jason Molenda <jmolenda@apple.com> Change UnwindLLDB::SearchForSavedLocationForRegister so that it will allow for
the link register save location being in the link register - in which case we
should iterate down the stack, not recursively try to find the lr in the current
frame over and over.

<rdar://problem/13932954>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@183282 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
8d31894e1157c1fba5084115ad1ce60e530362f2 13-Apr-2013 Jason Molenda <jmolenda@apple.com> Handle an edge case where we step into a function whose UnwindPlan
defines a Return Address register (e.g. lr on arm) but the RA register
hasn't been saved anywhere yet -- it is still in a live reg.
<rdar://problem/13503130>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179431 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
952e9dc874944fcdbbb224f3ec4fc2c859376f64 28-Mar-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13521159>

LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.

All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178191 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
a7e864cb0a450c7ef65b6f9f6c9bae839c405906 23-Feb-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13265297>

StackFrame assumes m_sc is additive, but m_sc can lose its target. So now the SymbolContext::Clear() method takes a bool that indicates if the target should be cleared. Modified all existing code to properly set the bool argument.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@175953 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
36da2aa6dc5ad9994b638ed09eb81c44cc05540b 25-Jan-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13069948>

Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.

So I defined a new "lldb::offset_t" which should be used for all file offsets.

After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.

Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@173463 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
b9db9d5bb01963774f28540dbe2c5a11f586ff29 07-Dec-2012 Daniel Malea <daniel.malea@intel.com> Fix a few more clang (3.2) warnings on Linux:
- remove unused members
- add NO_PEDANTIC to selected Makefiles
- fix return values (removed NULL as needed)
- disable warning about four-char-constants
- remove unneeded const from operator*() declaration
- add missing lambda function return types
- fix printf() with no format string
- change sizeof to use a type name instead of variable name
- fix Linux ProcessMonitor.cpp to be 32/64 bit friendly
- disable warnings emitted by swig-generated C++ code

Patch by Matt Kopec!



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169645 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
5f35a4be95aed0e5b2cb36f7d785bcbfc67284ae 29-Nov-2012 Daniel Malea <daniel.malea@intel.com> Resolve printf formatting warnings on Linux:
- use macros from inttypes.h for format strings instead of OS-specific types

Patch from Matt Kopec!



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168945 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
8a318f2ee08330c7fec72fc0e016af6a0eb1e9fc 16-Nov-2012 Jason Molenda <jmolenda@apple.com> Change RegisterContextLLDB's unwind logging to report which stack frame
finally was able to restore a register, instead of just reporting the
frames that couldn't supply the reg.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168139 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
f26aaeadb1ac49430c23cfac45af727aa6937f28 16-Nov-2012 Jason Molenda <jmolenda@apple.com> A change in how we search for saved register values unintentionally
allowed volatile registers to be returned up the stack. That leads
to unexpected/incorrect values provided to the user and we need to
avoid that.
<rdar://problem/12714247>



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168123 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
37816a3429a075e19b74f64fd642d5a5d7ec6f2f 26-Oct-2012 Jason Molenda <jmolenda@apple.com> Add a new capability to RegisterContextLLDB: To recognize when the
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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166757 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
5d30ea748f55faa7542c1b3ba31fe36f402beee2 16-Oct-2012 Jason Molenda <jmolenda@apple.com> Add a new ABI plugin method which specifies whether the architecture
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>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166005 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
6f01c93497df194b6f2194630a81e87d806ce0e0 12-Oct-2012 Jim Ingham <jingham@apple.com> Bunch of cleanups for warnings found by the llvm static analyzer.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@165808 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
49ce8969d3154e1560106cfe530444c09410f217 29-Aug-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11757916>

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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162860 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
f68a2050b1a85de977829ffb7e327a991fddad33 18-Aug-2012 Jason Molenda <jmolenda@apple.com> Some eh_frame unwind instructions will define a return address register;
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>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162167 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
caadc0dd7796a04943c0d84f5e7bec3a78a502db 10-Aug-2012 Sean Callanan <scallanan@apple.com> Fixed a potential crash where we attempt to read
an invalid register.

<rdar://problem/12065366>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@161679 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
b386d82334b65fb984348f2027b1cb7714de993f 09-Aug-2012 Sean Callanan <scallanan@apple.com> Removed explicit NULL checks for shared pointers
and instead made us use implicit casts to bool.
This generated a warning in C++11.

<rdar://problem/11930775>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@161559 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
4a379b1194f3e6b308cd6e80b45d6ca5dd0aafd7 17-Jul-2012 Greg Clayton <gclayton@apple.com> Ran the static analyzer on the codebase and found a few things.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160338 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
68fa4ec4361d1ea5a78a8a7eba2b8015e3dd68f7 14-Jul-2012 Jason Molenda <jmolenda@apple.com> Switch nearly all of the use of the UnwindPlan::Row's to go through
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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160214 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
e021c5bc1cdccff90a5696cc3cfec1e3e9ed7e95 01-Mar-2012 Jason Molenda <jmolenda@apple.com> Remove the sanity checks from RegisterContextLLDB::InitializeZerothFrame
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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151796 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
23297a3797f0595d732f09d68eb29a603c8b6e4c 29-Feb-2012 Jason Molenda <jmolenda@apple.com> Fix a recursion that could happen when creating the first frame in
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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151714 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
92f1c2b3c6c70c7c9c892424d63cd1f33bb38a49 24-Feb-2012 Jim Ingham <jingham@apple.com> Patch from Filipe Cabecinhas fixing a typo in the "lldb unwind" log output.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151370 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
3508c387c3f0c9ecc439d98048fd7694d41bab1b 24-Feb-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/10103468>

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.




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151336 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
f4124deeb9532044a38c0774ced872f2709347da 21-Feb-2012 Greg Clayton <gclayton@apple.com> Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr
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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151009 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
13d24fb1817faa7ccc4cfd799113ba1a2b8968eb 29-Jan-2012 Greg Clayton <gclayton@apple.com> Switching back to using std::tr1::shared_ptr. We originally switched away
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).



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149207 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
55cbdad610df78f9f0fa26d294c09626263da4b5 10-Jan-2012 Jim Ingham <jingham@apple.com> Don't call lldb_private::Process::GetLoadAddressPermissions to sanity check the unwind addresses
when you already know that the address is contained in a bona fide function. This can be a
slow call.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147829 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
fc984a09c47b592e7cde20f163c1795a9e0f21fc 08-Jan-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/10645694>

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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147747 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
df192706ae5e99fd485d92a9797b546dd88296bb 16-Dec-2011 Jason Molenda <jmolenda@apple.com> When we're unwinding out of frame 0 and we end up with a bogus frame
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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@146723 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
84985174d8b0fe4913caf446f7789f1531317650 14-Dec-2011 Jason Molenda <jmolenda@apple.com> On Mac OS X the Objective-C runtime (libobjc) has many critical
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>



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@146551 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
9a1f001ebdc7745bfc5f4070b5fb6716e8a28856 13-Dec-2011 Jason Molenda <jmolenda@apple.com> Add two new memory region based checks to the Unwinder:

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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@146478 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
1f9c39c3c146f3c057575f53707e97019f402c46 13-Dec-2011 Jason Molenda <jmolenda@apple.com> When unwinding from the first frame, try to ask the remote debugserver
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>



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@146477 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
abe2d365bf9fd069c42ed41294975452a3df0fdb 01-Nov-2011 Jason Molenda <jmolenda@apple.com> Restructure the relationship between UnwindLLDB and the
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.




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@143423 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
5ce0e2b66812de585bc1a55b440cd6efd68bf247 18-Oct-2011 Jason Molenda <jmolenda@apple.com> Add code to RegisterContextLLDB::InitializeNonZerothFrame to detect a multiple stack frames
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.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@142331 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
2d9b29b4bdc88d319761cac07f1692eef95c2a72 30-Sep-2011 Jason Molenda <jmolenda@apple.com> Fix verbose logging of unwinders.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140817 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
5114e88ce51cd2ab45d0829e3f21ea8b2e16174d 16-Sep-2011 Jason Molenda <jmolenda@apple.com> Tighten up the 'log enable lldb unwind' printing for
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.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@139897 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
819dd5e0990e8550d0185f65cc5cf4bc3d9d1058 15-Sep-2011 Jason Molenda <jmolenda@apple.com> Have the FuncUnwinder object request & provide an architecture-defined
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();
}




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@139760 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
5c3861df62fde02d610a5ed92927a2d89333358b 02-Sep-2011 Greg Clayton <gclayton@apple.com> Added the ability for DWARF locations to use the ABI plug-ins to resolve
register names when dumping variable locations and location lists. Also did
some cleanup where "int" types were being used for "lldb::RegisterKind"
values.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@138988 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
63afdb07641f04aa7b60d895120b056124d3469b 17-Jun-2011 Greg Clayton <gclayton@apple.com> Improved the packet throughput when debugging with GDB remote by over 3x on
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@133224 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
75906e4ec98af3717e415727a8d663a4e246bb4f 11-May-2011 Greg Clayton <gclayton@apple.com> Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131193 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
061b79dbf1fefaf157d414747e98a463a0f32eda 09-May-2011 Greg Clayton <gclayton@apple.com> While implementing unwind information using UnwindAssemblyInstEmulation I ran
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 &reg_value) = 0;

virtual bool
WriteRegister (const RegisterInfo *reg_info, const RegisterValue &reg_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.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131096 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
97eecb1834431b39d4d58257f8ccfdea1db7f1de 25-Apr-2011 Greg Clayton <gclayton@apple.com> Put plug-ins into the correct directories as they were incorrectly located
in a Utility directory.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@130135 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
ff44ab42e9f5d8e4d550e11d1b69413e0bc75b71 23-Apr-2011 Greg Clayton <gclayton@apple.com> Fixed the SymbolContext::DumpStopContext() to correctly indent and dump
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.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@130044 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
dbeb3e1e038a75f00fd565203839020e1d00a7c6 11-Apr-2011 Stephen Wilson <wilsons@start.ca> Order of initialization lists.

This patch fixes all of the warnings due to unordered initialization lists.

Patch by Marco Minutoli.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@129290 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
85be6c9c0cca030226c7f2e17f073f36f838e042 22-Feb-2011 Greg Clayton <gclayton@apple.com> Remove an assertion that was causing a crash.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@126235 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
c3c4661c6a7527580e605dbb69bef7634971fe13 15-Feb-2011 Greg Clayton <gclayton@apple.com> All UnwindPlan objects are now passed around as shared pointers.

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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@125541 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
cd548034fa23113e995b8463d14f910ba2f7298c 01-Feb-2011 Greg Clayton <gclayton@apple.com> Endian patch from Kirk Beitz that allows better cross platform building.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124643 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
bdcb6abaa287df2c5f312c51d993c1d0b0cb120c 26-Jan-2011 Greg Clayton <gclayton@apple.com> Enabled extra warnings and fixed a bunch of small issues.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124250 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
1724dec0b9105792a65b06dc3a5141ea0feb1f06 17-Jan-2011 Greg Clayton <gclayton@apple.com> Avoid infinite loops in stack backtraces and renamed:

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.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123673 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
a875b64ab8d258b28959d05eea37cb5dfdd72730 09-Jan-2011 Greg Clayton <gclayton@apple.com> Put more smarts into the RegisterContext base class. Now the base class has
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123127 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
5382281cce4d2de419628a39b1284eca38b12d66 08-Jan-2011 Greg Clayton <gclayton@apple.com> Made FuncUnwinders threadsafe.

Other small cleanups as well.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123088 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
5d187e5495ee17f6763337a6ae28c2a7b07e4945 08-Jan-2011 Greg Clayton <gclayton@apple.com> Spelling changes applied from lldb_spelling.diffs from Bruce Mitchener.

Thanks Bruce!



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123083 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
08d7d3ae16110aa68ed40c161eac8571aeb94cd9 06-Jan-2011 Greg Clayton <gclayton@apple.com> Fixed issues with RegisterContext classes and the subclasses. There was
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@122976 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
d4c5cd5e19263c8ab8042355ca55541a4901982f 22-Dec-2010 Jason Molenda <jmolenda@apple.com> RegisterContextLLDB.cpp (InitializeNonZerothFrame): If we get a
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.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@122386 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
8e69de4b9c55ec2eaebc62e4d987c2f0618ac431 20-Nov-2010 Jason Molenda <jmolenda@apple.com> Change the DWARFExpression::Evaluate methods to take an optional
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@119885 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
e4b078491287a6c4d4ab0828fcfb2af87627d19f 12-Nov-2010 Jason Molenda <jmolenda@apple.com> I'm not thrilled with how I structured this but RegisterContextLLDB
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118882 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
2ecd040084cdd0fc26c731baba069e7b1300575c 09-Nov-2010 Jason Molenda <jmolenda@apple.com> Implement RegisterContext::WriteRegisterBytes in RegisterContextLLDB.
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118486 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
d6ef16aab825a1319179d1445f35538f535e9bf1 09-Nov-2010 Jason Molenda <jmolenda@apple.com> Fix thinko in UnwindTable.cpp where it wouldn't provde a
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118467 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
e005f2ce03c489ebde9110678a29cbfe8488d5b4 06-Nov-2010 Greg Clayton <gclayton@apple.com> Modified all logging calls to hand out shared pointers to make sure we
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118319 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
a6b71de68536fd9c9917f59e42f1d8e39b06f8fc 04-Nov-2010 Jason Molenda <jmolenda@apple.com> Built the native unwinder with all the warnings c++-4.2 could muster;
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118240 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
800d11d87769e1a7083f7a5545613625396deb3e 04-Nov-2010 Jason Molenda <jmolenda@apple.com> Handle the case where no eh_frame section is present.

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.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118218 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
4e12194c2d784868e5d2236f9546de104531bdc0 26-Oct-2010 Jason Molenda <jmolenda@apple.com> Add an unwind log Printf to note when an eh_frame section is
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@117361 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
2e2ba54cd99786dddebc0c690a97d8c69b50974a 26-Oct-2010 Jason Molenda <jmolenda@apple.com> Don't indent log lines by frame # spaces if the frame # exceeds 100 - the indentation
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.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@117350 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
a2c269c017d37b3e35f461af52e11cdd6300d5e4 26-Oct-2010 Jason Molenda <jmolenda@apple.com> Get a disassembler based on the correct architecture for assembly
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.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@117343 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
8280cbe80c79bc206335831dd732e0f9fb69c519 25-Oct-2010 Jason Molenda <jmolenda@apple.com> Check in the native lldb unwinder.

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).



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@117256 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp