e6017d3908c724f6a11b0b77f19f42d793b9e56f |
|
29-Jul-2013 |
Ashok Thirumurthi <ashok.thirumurthi@intel.com> |
Adds a DW_OP_call_frame_cfa handler when evaluating DWARF 3/4 expressions in LLDB that load the canonical frame address rather than a location list. - Handles the simple case where a CFA can be pulled from the current stack frame. - Fixes more than one hundred failing tests with gcc 4.8! TODO: Use UnwindPlan::GetRowForFunctionOffset if the DWARFExpression needs to be evaluated in a context analogous to a virtual unwind (perhaps using RegisterContextLLDB). - Also adds some comments to DWARFCallFrameInfo whenever I got confused. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@187361 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/DWARFCallFrameInfo.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/Symbol/DWARFCallFrameInfo.cpp
|
7b48427713eb1cec376091a3e50619425165eaa4 |
|
23-Mar-2013 |
Jason Molenda <jmolenda@apple.com> |
Don't bother calling Reserve on the vector unless we have entries to be added. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177776 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/DWARFCallFrameInfo.cpp
|
2d63ae1820e622335caf58f86a86164a2a160931 |
|
22-Mar-2013 |
Jason Molenda <jmolenda@apple.com> |
Add a Reserve method to RangeVector and RangeDataVector. Have the DWARFCallFrameInfo method which returns a RangeVector pre-size the vector based on the number of entries it will be adding insted of growing the vector as items are added. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177773 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/DWARFCallFrameInfo.cpp
|
d793839192c6351a1615cf723564ef672bd8b877 |
|
21-Mar-2013 |
Jason Molenda <jmolenda@apple.com> |
Add a new method GetFunctionAddressAndSizeVector to DWARFCallFrameInfo. This returns a vector of <file address, size> entries for all of the functions in the module that have an eh_frame FDE. Update ObjectFileMachO to use the eh_frame FDE function addresses if the LC_FUNCTION_STARTS section is missing, to fill in the start addresses of any symbols that have been stripped from the binary. Generally speaking, lldb works best if it knows the actual start address of every function in a module - it's especially important for unwinding, where lldb inspects the instructions in the prologue of the function. In a stripped binary, it is deprived of this information and it reduces the quality of our unwinds and saved register retrieval. Other ObjectFile users may want to use the function addresses from DWARFCallFrameInfo to fill in any stripped symbols like ObjectFileMachO does already. <rdar://problem/13365659> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177624 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/DWARFCallFrameInfo.cpp
|
c953b5647a8c451113c21e0e367194cad9efeb0e |
|
20-Mar-2013 |
Jason Molenda <jmolenda@apple.com> |
Change DWARFCallFrameInfo from using a vector of AddressRanges to track the EH FDEs for the functions in a module to using a RangeDataVector, a more light-weight data structure that only refers to File addresses. Makes the initial FDE scan about 3x faster, uses less memory. <rdar://problem/13465650> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177585 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/DWARFCallFrameInfo.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/Symbol/DWARFCallFrameInfo.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/Symbol/DWARFCallFrameInfo.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/Symbol/DWARFCallFrameInfo.cpp
|
1cddbaac865a0f2f0cca2230326bc240d849f18a |
|
01-Aug-2012 |
Jason Molenda <jmolenda@apple.com> |
When building up the UnwindPlan based on eh_frame unwind instructions, be sure to allocate new UnwindPlan::Row's each time we push a row on to the UnwindPlan so we don't mutate it any further. (fallout from changing the UnwindPlan from having a vector of Row's to having a vector of RowSP shared pointers.) <rdar://problem/11997385> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@161089 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/DWARFCallFrameInfo.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/Symbol/DWARFCallFrameInfo.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/Symbol/DWARFCallFrameInfo.cpp
|
c529786f590044117cc96f55137ea7db4e1b92ed |
|
12-Jul-2012 |
Sean Callanan <scallanan@apple.com> |
Added a mutex to the call frame info to guard generation of the FDE index. <rdar://problem/11813705> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160099 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/DWARFCallFrameInfo.cpp
|
b5a8f1498e1ddaeed5187a878d57ea0b74af9c26 |
|
05-Feb-2012 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/10560053> Fixed "target modules list" (aliased to "image list") to output more information by default. Modified the "target modules list" to have a few new options: "--header" or "-h" => show the image header address "--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library) Removed the "--symfile-basename" or "-S" option, and repurposed it to "--symfile-unique" "-S" which will show the symbol file if it differs from the executable file. ObjectFile's can now be loaded from memory for cases where we don't have the files cached locally in an SDK or net mounted root. ObjectFileMachO can now read mach files from memory. Moved the section data reading code into the ObjectFile so that the object file can get the section data from Process memory if the file is only in memory. lldb_private::Module can now load its object file in a target with a rigid slide (very common operation for most dynamic linkers) by using: bool Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed) lldb::SBModule() now has a new constructor in the public interface: SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr); This will find an appropriate ObjectFile plug-in to load an image from memory where the object file header is at "header_addr". git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149804 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/DWARFCallFrameInfo.cpp
|
df6dc88322f103b263092d752db4490e628a1cbd |
|
05-Jan-2012 |
Greg Clayton <gclayton@apple.com> |
Added code in the Host layer that can report system log messages so that we don't have "fprintf (stderr, ...)" calls sprinkled everywhere. Changed all needed locations over to using this. For non-darwin, we log to stderr only. On darwin, we log to stderr _and_ to ASL (Apple System Log facility). This will allow GUI apps to have a place for these error and warning messages to go, and also allows the command line apps to log directly to the terminal. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147596 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/DWARFCallFrameInfo.cpp
|
d2909b4fdbf504f5c182fad7dbee0c1b0f6f5c68 |
|
29-Dec-2011 |
Greg Clayton <gclayton@apple.com> |
Centralize the code the reads the CFI so that we always log. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147330 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/DWARFCallFrameInfo.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/Symbol/DWARFCallFrameInfo.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/Symbol/DWARFCallFrameInfo.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/Symbol/DWARFCallFrameInfo.cpp
|
b344843f75ef893762c93fd0a22d2d45712ce74d |
|
24-Mar-2011 |
Greg Clayton <gclayton@apple.com> |
Fixed the LLDB build so that we can have private types, private enums and 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. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128239 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/DWARFCallFrameInfo.cpp
|
db599d3bf4f67fbee6635cbb99a409baa7ba2842 |
|
25-Jan-2011 |
Jason Molenda <jmolenda@apple.com> |
Revert one unintended change checked in to DWARFCallFrameInfo.cpp with my last commit. The change should be correct but it's not fixing anything important and right now unneeded changes are not a good idea. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124173 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/DWARFCallFrameInfo.cpp
|
d03b25acc9efad8b1381d900efcf71d49ca6a859 |
|
25-Jan-2011 |
Jason Molenda <jmolenda@apple.com> |
Use new Section::IsEncrypted() method to check if the eh_frame section is encrypted before trying to read it. Fixes assert / crash when trying to unwind an executable w/ encrypted eh_frame sect. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124172 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/DWARFCallFrameInfo.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/Symbol/DWARFCallFrameInfo.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/Symbol/DWARFCallFrameInfo.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/Symbol/DWARFCallFrameInfo.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/Symbol/DWARFCallFrameInfo.cpp
|
3a4ea24572fad1e22525f8efb718d49d41e30398 |
|
10-Sep-2010 |
Jason Molenda <jmolenda@apple.com> |
The first part of an lldb native stack unwinder. 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. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113581 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/DWARFCallFrameInfo.cpp
|
bef1583b89e73de77c8b0897fcf42b5b1fcabe4c |
|
14-Jul-2010 |
Greg Clayton <gclayton@apple.com> |
I enabled some extra warnings for hidden local variables and for hidden virtual functions and caught some things and did some general code cleanup. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@108299 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/DWARFCallFrameInfo.cpp
|
ccfba727178bb919cdff3365839bed9584df2560 |
|
07-Jul-2010 |
Jason Molenda <jmolenda@apple.com> |
Switch over to using llvm's dwarf constants file. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@107716 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/DWARFCallFrameInfo.cpp
|
24943d2ee8bfaa7cf5893e4709143924157a5c1e |
|
08-Jun-2010 |
Chris Lattner <sabre@nondot.org> |
Initial checkin of lldb code from internal Apple repo. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105619 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Symbol/DWARFCallFrameInfo.cpp
|