summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix several issues around .ARM.exidx section handlingTamas Berghammer2015-10-021-10/+10
| | | | | | | | | | | | | | * Use .ARM.exidx as a fallback unwind plan for non-call site when the instruction emulation based unwind failed. * Work around an old compiler issue where the compiler isn't sort the entries in .ARM.exidx based on their address. * Fix unwind info parsing when the virtual file address >= 0x80000000 * Fix bug in unwind info parsing when neither lr nor pc is explicitly restored. Differential revision: http://reviews.llvm.org/D13380 llvm-svn: 249119
* Add support for .ARM.exidx unwind informationTamas Berghammer2015-09-301-8/+23
| | | | | | | | | .ARM.exidx/.ARM.extab sections contain unwind information used on ARM architecture from unwinding from an exception. Differential revision: http://reviews.llvm.org/D13245 llvm-svn: 248903
* Change the looping stack detection codeTamas Berghammer2015-09-091-14/+16
| | | | | | | | | | | In some special case (e.g. signal handlers, hand written assembly) it is valid to have 2 stack frame with the same CFA value. This CL change the looping stack detection code to report a loop only if at least 3 consecutive frames have the same CFA. Differential revision: http://reviews.llvm.org/D12699 llvm-svn: 247133
* Handle DW_OP_GNU_addr_index in DWARF expressionsTamas Berghammer2015-08-251-2/+10
| | | | | | Differential revision: http://reviews.llvm.org/D12290 llvm-svn: 245932
* Enable usage of eh_frame based unwind plan as a fallbackTamas Berghammer2015-07-031-12/+39
| | | | | | | | | | | Previously if the instruction emulation based unwind plan failed then we fall back to the arch default unwind plan. Change it to fall back to the eh_frame based one even on non call sites if we have eh_frame as that one tend to be more reliable. Differential revision: http://reviews.llvm.org/D10902 llvm-svn: 241334
* Improve instruction emulation based stack unwinding on ARMTamas Berghammer2015-06-241-11/+8
| | | | | | | | | | | | | | | | | | | | | | | * Add and fix the emulation of several instruction. * Disable frame pointer usage on Android. * Specify return address register for the unwind plan instead of explict tracking the value of RA. * Replace prologue detection heuristics (unreliable in several cases) with a logic to follow the branch instructions and restore the CFI value based on them. The target address for a branch should have the same CFI as the source address (if they are in the same function). * Handle symbols in ELF files where the symbol size is not specified with calcualting their size based on the next symbol (already done in MachO files). * Fix architecture in FuncUnwinders with filling up the inforamtion missing from the object file with the architecture of the target. * Add code to read register wehn the value is set to "IsSame" as it meanse the value of a register in the parent frame is the same as the value in the current frame. Differential revision: http://reviews.llvm.org/D10447 llvm-svn: 240533
* Fix printing of function names during unwind logging.Zachary Turner2015-04-061-6/+15
| | | | llvm-svn: 234172
* Support evaluation of DWARF expressions setting CFAPavel Labath2015-02-231-1/+22
| | | | | | | | | | | | | | | | | | | | | Summary: This patch enables evaluation of DWARF expressions setting the CFA during stack unwinding. This makes TestSigtrampUnwind "almost" pass on linux. I am not enabling the test yet since the symbol name for the signal trampoline does not get resolved properly due to a different bug, but apart from that, the backtrace is sane. I am unsure how this change affects Mac. I think it makes the unwinder prefer the DWARF unwind plan instead of some custom platform-dependant plan. However, it does not affect the end result - the stack unwinding works as expected. Reviewers: jasonmolenda Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D7792 llvm-svn: 230211
* UnwindPlan::Row refactor -- add support for CFA set by a DWARF expressionPavel Labath2015-02-231-37/+49
| | | | | | | | | | | | | | | | | | | Summary: This change refactors UnwindPlan::Row to be able to store the fact that the CFA is value is set by evaluating a dwarf expression (DW_CFA_def_cfa_expression). This is achieved by creating a new class CFAValue and moving all CFA setting/getting code there. Note that code using the new CFAValue::isDWARFExpression is not yet present and will be added in a follow-up patch. Therefore, this patch should not change the functionality in any way. Test Plan: Ran tests on Mac and Linux. No regressions detected. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D7755 llvm-svn: 230210
* Adding compact unwind as a source of unwind information Jason Molenda2015-01-211-2/+5
| | | | | | | | | | | | | | introduced subtle bugs in two places in RegisterContextLLDB::GetFullUnwindPlanForFrame where it specifically wanted to get an eh_frame unwind plan and was using "Get CallSite UnwindPlan" as synonymous with that. But now we have two different types of unwind plan that can be returned in that case, and compact unwind won't behaves as needed. <rdar://problem/19528559> llvm-svn: 226631
* Rearrange RegisterContextLLDB::SavedLocationForRegister a tiny bitJason Molenda2015-01-081-18/+22
| | | | | | | | | | | | | so that we will use the UnwindPlan's rule for providing the stack pointer BEFORE we use the trick of using the callee's CFA address as the stack pointer. When we're in a _sigtramp frame, the CFA of the _sigtramp stack frame is not the same as the stack pointer value when the async interrupt occurred -- we need to use the eh_frame rules for retrieving the correct value. <rdar://problem/18913548> llvm-svn: 225427
* Add a new 'eRegisterInLiveRegisterContext' RegisterLocation to trackJason Molenda2014-12-091-8/+34
| | | | | | | | | | | | | | a register value that is live in the stack frame 0 register context. Fixes a problem where retrieving a register value on stack frame #n would involved O(n!) stack frame checks. This could be very slow on a deep stack when retrieving register values that had not been modified/saved by any of the stack frames. Not common, but annoying when it was hit. <rdar://problem/19010211> llvm-svn: 223843
* The lldb unwinder can now use the unwind information from the compact-unwind Jason Molenda2014-12-081-4/+7
| | | | | | | | | | | | | | | | | | section for x86_64 and i386 targets on Darwin systems. Currently only the compact unwind encoding for normal frame-using functions is supported but it will be easy handle frameless functions when I have a bit more free time to test it. The LSDA and personality routines for functions are also retrieved correctly for functions from the compact unwind section. This new code is very fresh -- it passes the lldb testsuite and I've done by-hand inspection of many functions and am getting correct behavior for all of them. There may need to be some bug fixing over the next couple weeks as I exercise and test it further. But I think it's fine right now so I'm committing it. <rdar://problem/13220837> llvm-svn: 223625
* When a RegisterContext produces an invalid CFA address, changeJason Molenda2014-11-221-7/+17
| | | | | | | | | | | | | | | | | UnwindLLDB::AddOneMoreFrame to try the fallback unwind plan on that same stack frame before it tries the fallback unwind plan on the "next" or callee frame. In RegisterContextLLDB::TryFallbackUnwindPlan, when we're trying the fallback unwind plan to see if it is valid, make sure we change all of the object ivars that might be used in the process of fetching the CFA & caller's saved pc value and restore those if we decide not to use the fallback unwindplan. <rdar://problem/19035079> llvm-svn: 222601
* Add additional checks to the SavedLocationForRegister methodJason Molenda2014-11-191-5/+28
| | | | | | | | | | | | | | where it is retrieving the Return Address register contents on a target where that's a thing. If we fail to get a valid RA, we force a switch to the fallback unwind plan. This patch adds a sanity check for that fallback unwind plan -- it must get a valid CFA for this frame in addition to being able to retrieve the caller's PC -- and it correctly marks the unwind rules as failing if the fallback unwind plan fails. <rdar://problem/19010211> llvm-svn: 222301
* A pretty big overhaul of the TryFallbackUnwindPlan method inJason Molenda2014-11-131-51/+219
| | | | | | | | | | | | RegisterContextLLDB. I have core files of half a dozen tricky unwind situations on x86/arm and they're all working pretty much correctly at this point, but we'll need to keep an eye out for unwinder regressions for a little while; it's tricky to get these heuristics completely correct in all unwind situations. <rdar://problem/18937193> llvm-svn: 221866
* Use PRIx64 when printing addr_t's. Don't need to force full-width 0 paddingJason Molenda2014-11-121-2/+2
| | | | | | with addresses that aren't designed to be column-aligned across multiple lines. llvm-svn: 221810
* Avoid crash in InitializeNonZerothFrame if no module foundEd Maste2014-11-121-1/+2
| | | | | | | | After r221575 TestCallStopAndContinue and TestCallThatRestarts started crashing on FreeBSD with a null temporary_module_sp in RegisterContextLLDB::InitializeNonZerothFrame(). llvm-svn: 221805
* FIx a bug with PC-register handling in a RA register.Justin Hibbits2014-11-121-0/+1
| | | | | | | | | | | The addition of RegisterNumber introduced a bug where if the PC is stored in a return address register, such as on ARM and PowerPC, this register number is retrieved and used, but never checked in the row if it's saved. Correct this by setting the variable that's used to the new register number. Patch by Jason Molenda. llvm-svn: 221790
* Add an alternative CFA type.Justin Hibbits2014-11-121-25/+42
| | | | | | | | | | | | | | | | | | | Summary: PowerPC handles the stack chain with the current stack pointer being a pointer to the backchain (CFA). LLDB currently has no way of handling this, so this adds a "CFA is dereferenced from a register" type. Discussed with Jason Molenda, who also provided the initial patch for this. Reviewers: jasonmolenda Reviewed By: jasonmolenda Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D6182 llvm-svn: 221788
* Add an operator== to the RegisterNumber class; it simplifiesJason Molenda2014-11-111-6/+6
| | | | | | RegisterContextLLDB a bit more in a few places. llvm-svn: 221677
* Add a RegisterNumber class to RegisterContextLLDB.h and start usingJason Molenda2014-11-081-73/+96
| | | | | | | | | | | | | | | | | | | | | | | it in RegisterContext.cpp. There's a lot of bookkeeping code in RegisterContextLLDB where it has to convert between different register numbering schemes and it makes some methods like SavedLocationForRegister very hard to read or maintain. Abstract all of the details about different register numbering systems for a given register into this new class to make it easier to understand what the method is doing. Also add register name printing to all of the logging -- that's easy to get now that I've got an object to represent the register numbers. There were some gnarly corner cases of this method that I believe I've translated correctly - initial testing looks good but it's possible I missed a corner case, especially with architectures which uses a link-register aka return address register like arm32/arm64. Basic behavior is correct but there are a lot of corner casese that are handled in this method ... llvm-svn: 221577
* Fix a corner case with the handling of noreturn functions.Jason Molenda2014-11-081-9/+45
| | | | | | | | | | | | | | | | | | If a noreturn function was the last function in a section, we wouldn't correctly back up the saved-pc value into the correct section leading to us showing the wrong function in the backtrace. Also add a backtrace test with an attempt to elicit this particular layout. It happens to work out with clang -Os but other compilers may not quite get the same layout I'm getting at that opt setting. We'll still be exercising the basic noreturn handling in the unwinder even if we don't get one function at the very end of a section. <rdar://problem/16051613> llvm-svn: 221575
* Add one extra sanity check to RegisterContextLLDB::TryFallbackUnwindPlanJason Molenda2014-11-041-0/+8
| | | | | | | so it doesn't try the arch default if a comiler-generated (eh_frame, compact unwind info) based unwind plan has failed. llvm-svn: 221239
* Back out r221229 -- instead of trying to identify the end of the unwind,Jason Molenda2014-11-041-27/+8
| | | | | | | | | | | | | | | | | let's let lldb try the arch default unwind every time but not destructively -- it doesn't permanently replace the main unwind method for that function from now on. This fix is for <rdar://problem/18683658>. I tested it against Ryan Brown's go program test case and also a collection of core files of tricky unwind scenarios <rdar://problem/15664282> <rdar://problem/15835846> <rdar://problem/15982682> <rdar://problem/16099440> <rdar://problem/17364005> <rdar://problem/18556719> that I've fixed over the last 6-9 months. llvm-svn: 221238
* After we've completed a full backtrace, we'll have one frame whichJason Molenda2014-11-041-1/+17
| | | | | | | | | | | | | | | | is "invalid" -- it is past the end of the stack trace. Add a new method IsCompletedStackWalk() so we can tell if an invalid stack frame is from a complete backtrace or if it might be worth re-trying the last unwind with a different method. This fixes the unwinder problems Ryan Brown was having with go programs. The unwinder can (under the right circumstances) still destructively replace unwind plans permanently - I'll work on that in a different patch. <rdar://problem/18683658> llvm-svn: 221229
* Be more consistent about null checks for the Process and ABIJason Molenda2014-10-151-7/+14
| | | | | | | | in GetFullUnwindPlanForFrame() - the code was mostly checking that we had an active Process and ABI but not always. clang static analyzer fixit. llvm-svn: 219772
* When we detect a stack unwind loop, before we abortJason Molenda2014-10-071-6/+14
| | | | | | | | the backtrace, try falling back to the architecture default unwind plan and see if we can backtrace a little further. <rdar://problem/18556719> llvm-svn: 219247
* RegisterContextLLDB::InitializeNonZerothFrame had a bit of code toJason Molenda2014-09-021-17/+28
| | | | | | | | | | | | | | | | | | | | detct unwind loops but there was a code path through there (using architecture default unwind plans) that didn't do the check, and could end up with an infinite loop unwind. Move that code into a separate method and call it from both places where it is needed. Also remove the use of ABI::FunctionCallsChangeCFA in that check. I thought about it a lot and none of the architecutres that we're supporting today can have a looping CFA. Since the unwinder isn't using ABI::FunctionCallsChangeCFA() and ABI::StackUsesFrames(), and the unwinder was the only reason those methods exists, I removed them from the ABI and all its plugins. <rdar://problem/17364005> llvm-svn: 216992
* On x86 & x86_64, try to use eh_frame for frame 0.Todd Fiala2014-08-251-2/+2
| | | | | | | | | | | | | We decided to use assmbly profiler instead of eh_frame for frame 0 because for compiler generated code, eh_frame is usually synchronous(a.k.a. only valid at call site); and we have no way to tell if it's asynchronous or not. But for x86 & x86_64 compiler generated code: 1. clang & GCC describes all prologue instructions in eh_frame; 2. mid-function stack pointer altering instructions can be easily detected. So we can grab eh_frame, and use assembly profiler to augment it into asynchronous unwind table. This change also benefits hand-written assembly; eh_frame for hand-written assembly is often asynchronous,so we have a much better chance to successfully unwind through them. Change by Tong Shen. llvm-svn: 216406
* Replace uint32_t by lldb::RegisterKing in register context API.Jean-Daniel Dupas2014-07-021-5/+5
| | | | llvm-svn: 212172
* Add a check that we found an ABI plugin before calling a method on it.Jason Molenda2014-06-131-1/+1
| | | | llvm-svn: 210942
* JITed functions can now have debug info and be debugged with debug and ↵Greg Clayton2014-03-241-14/+17
| | | | | | | | | | | | | | | | | | | source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
* Fix unwind_plan test conditions (could result in NULL memory access).Virgile Bello2014-03-091-1/+1
| | | | llvm-svn: 203385
* Add a new idea of a "fallback" UnwindPlan to the RegisterContextLLDBJason Molenda2014-02-211-49/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | class. If we try to unwind a stack frame to find a caller stack frame, and we fail to get a valid-looking frame, AND if the UnwindPlan we used is an assembly-inspection based UnwindPlan, then we should throw away the assembly-inspection UnwindPlan and try unwinding with the architectural default UnwindPlan. This code path won't be taken if eh_frame unwind instructions are available - lldb will always prefer those once it's off the zeroth frame. The problem I'm trying to fix here is the class of unwind failures that happen when we have hand-written assembly on the stack, with no eh_frame, and lldb's assembly parser fails to understand the assembly. People usually write their hand-written assembly to follow the frame-pointer-preserving conventions of the platform so the architectural default UnwindPlan will often work. We won't have the spill location for most of the non-volatile registers if we fall back to this, but it's better than stopping the unwind prematurely. This is a bit of a tricky change that I believe is correct, but if we get unwinds that go of into the weeds / unwind bogus frames at the end of the stack, I'll need to revisit it. <rdar://problem/16099440> llvm-svn: 201839
* Add a new target setting, trap-handler-names, where a user canJason Molenda2014-02-141-26/+43
| | | | | | | | | | | | specify a list of functions which should be treated as trap handlers. This will be primarily useful to people working in non-user-level process debugging - kernels and other standalone environments. For most people, the trap handler functions provided by the Platform plugin will be sufficient. <rdar://problem/15835846>, <rdar://problem/15982682> llvm-svn: 201386
* The Platform base class now maintains a list of trap handlersJason Molenda2014-02-131-28/+38
| | | | | | | | | | | | | | | | aka asynchronous signal handlers, which subclasses should fill in as appropriate. For most Unix user process environments, the one entry in this list is _sigtramp. For bare-board and kernel environments, there will be different sets of trap handlers. The unwinder needs to know when a frame is a trap handler because the rules it enforces for the frame "above" the trap handler is different from most middle-of-the-stack frames. <rdar://problem/15835846> llvm-svn: 201300
* Fix for failure to unwind Linux stack frames with call in final position.Todd Fiala2014-02-011-4/+37
| | | | | | | | | | | | | | | Fixes http://llvm.org/bugs/show_bug.cgi?id=18656. Note this exposes a failure on Linux of TestInferiorAssert.test_inferior_asserting_disassemble, similar to how it fails on FreeBSD. I'll file a bug for this next. We're now getting another frame beyond where we used to prior to this fix, so the fix is exposing failures in previosly not-reachable frames. Much thanks to Jason Molenda, who had much to do with helping figure out where unwinding was breaking. llvm-svn: 200600
* Add the offset for cfa+offset log messages in the unwind channel, to aid in ↵Jason Molenda2014-01-101-2/+2
| | | | | | debugging. llvm-svn: 198977
* Use Address::SetLoadAddress() instead of SectionLoadList::ResolveLoadAddress().Jason Molenda2014-01-041-3/+3
| | | | | | | | | The former will set the Address object's offset to the load address value if it is not present in any section; the latter will only set the Address object if the load addr is contained in one of its sections. <rdar://problem/15135987> llvm-svn: 198469
* Don't enforce ABI stack alignment rules on the sigtramp frame --Jason Molenda2014-01-031-0/+6
| | | | | | | | | | its stack frame is a constructed, fake thing that may not conform correctly to these rules. This fixes a problem where lldb couldn't backtrace past an asynchronous signal handler (_sigtramp) frame on a stack on Mac OS X. <rdar://problem/15035673> llvm-svn: 198450
* Partially revert a patch from Ashok Thirumurthi in r191430.Jason Molenda2013-12-201-0/+16
| | | | | | | | | | | The original code was not completely correct, but a form of this check is necessary to avoid an infinite recursion on some unwind cases where a function unwinds to itself with the same CFA. Ashok thought the recursion would be caught in RegisterContextLLDB but this one isn't - we still need it here. <rdar://problem/15664282> llvm-svn: 197761
* Revert one part of Ashok Thirumurthi's patch from September 16, r190812.Jason Molenda2013-12-191-6/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In those set of patches, Ashok changed Module::ResolveSymbolContextForAddress so that if it failed to find a symbol for a pc, it could back up the pc value by 1 and re-search for a symbol. His change to RegisterContextLLDB.cpp partially duplicates that behavior but it also removes the separate case where we find a Symbol for the pc address but it's the wrong symbol -- we need to handle this as well as the lookup-by-pc-finds-no-symbol case. The most obvious fallout from this regression was that lldb on Mac OS X couldn't backtrace past __assert_rtn() which tail-calls abort(). e.g. (lldb) bt * thread #1: tid = 0x5d6ea1, 0x00007fff8ee80866 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT * frame #0: 0x00007fff8ee80866 libsystem_kernel.dylib`__pthread_kill + 10 frame #1: 0x00007fff8eb5835c libsystem_pthread.dylib`pthread_kill + 92 frame #2: 0x00007fff8852ab1a libsystem_c.dylib`abort + 125 frame #3: 0x00007fff884f49bf libsystem_c.dylib`__assert_rtn + 321 frame #4: 0x0000000100000f2c a.out`main + 124 (lldb) dis -c 3 -s 0x7fff884f49b3 libsystem_c.dylib`__assert_rtn + 309: 0x7fff884f49b3: movq %rax, -0x11b96242(%rip) ; gCRAnnotations + 8 0x7fff884f49ba: callq 0x7fff8854fd2c ; symbol stub for: abort libsystem_c.dylib`basename: 0x7fff884f49bf: pushq %rbp (lldb) in this case, __assert_rtn() is immediately followed by basename() and the changes in r190812 didn't back up the pc value to get the correct function name / unwind info. <rdar://problem/15367233> llvm-svn: 197655
* For logical backtrace work, lldb needs to track Module unloads etc & ↵Greg Clayton2013-12-061-0/+1
| | | | | | | | | | symoblicate an address based on a point in time <rdar://problem/15314403> This patch adds a new lldb_private::SectionLoadHistory class that tracks what shared libraries were loaded given a process stop ID. This allows us to keep a history of the sections that were loaded for a time T. Many items in history objects will rely upon the process stop ID in the future. llvm-svn: 196557
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-1/+1
| | | | | | | | | | pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
* Add a new base class, Frame. It is a pure virtual function whichJason Molenda2013-11-021-1/+1
| | | | | | | | | | | | | | | | | | | | | defines a protocol that all subclasses will implement. StackFrame is currently the only subclass and the methods that Frame vends are nearly identical to StackFrame's old methods. Update all callers to use Frame*/Frame& instead of pointers to StackFrames. This is almost entirely a mechanical change that touches a lot of the code base so I'm committing it alone. No new functionality is added with this patch, no new subclasses of Frame exist yet. I'll probably need to tweak some of the separation, possibly moving some of StackFrame's methods up in to Frame, but this is a good starting point. <rdar://problem/15314068> llvm-svn: 193907
* Added support for reading thread-local storage variables, as defined using ↵Richard Mitton2013-10-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | the __thread modifier. To make this work this patch extends LLDB to: - Explicitly track the link_map address for each module. This is effectively the module handle, not sure why it wasn't already being stored off anywhere. As an extension later, it would be nice if someone were to add support for printing this as part of the modules list. - Allow reading the per-thread data pointer via ptrace. I have added support for Linux here. I'll be happy to add support for FreeBSD once this is reviewed. OS X does not appear to have __thread variables, so maybe we don't need it there. Windows support should eventually be workable along the same lines. - Make DWARF expressions track which module they originated from. - Add support for the DW_OP_GNU_push_tls_address DWARF opcode, as generated by gcc and recent versions of clang. Earlier versions of clang (such as 3.2, which is default on Ubuntu right now) do not generate TLS debug info correctly so can not be supported here. - Understand the format of the pthread DTV block. This is where it gets tricky. We have three basic options here: 1) Call "dlinfo" or "__tls_get_addr" on the inferior and ask it directly. However this won't work on core dumps, and generally speaking it's not a good idea for the debugger to call functions itself, as it has the potential to not work depending on the state of the target. 2) Use libthread_db. This is what GDB does. However this option requires having a version of libthread_db on the host cross-compiled for each potential target. This places a large burden on the user, and would make it very hard to cross-debug from Windows to Linux, for example. Trying to build a library intended exclusively for one OS on a different one is not pleasant. GDB sidesteps the problem and asks the user to figure it out. 3) Parse the DTV structure ourselves. On initial inspection this seems to be a bad option, as the DTV structure (the format used by the runtime to manage TLS data) is not in fact a kernel data structure, it is implemented entirely in useerland in libc. Therefore the layout of it's fields are version and OS dependent, and are not standardized. However, it turns out not to be such a problem. All OSes use basically the same algorithm (a per-module lookup table) as detailed in Ulrich Drepper's TLS ELF ABI document, so we can easily write code to decode it ourselves. The only question therefore is the exact field layouts required. Happily, the implementors of libpthread expose the structure of the DTV via metadata exported as symbols from the .so itself, designed exactly for this kind of thing. So this patch simply reads that metadata in, and re-implements libthread_db's algorithm itself. We thereby get cross-platform TLS lookup without either requiring third-party libraries, while still being independent of the version of libpthread being used. Test case included. llvm-svn: 192922
* Change two new logging messages from verbose-only to non-verboseJason Molenda2013-10-031-2/+2
| | | | | | | in the unwinder - they're important to flag when debugging an unwind problem. llvm-svn: 191882
* Tweak logging messages from Ed's prev commit to make it a little moreJason Molenda2013-10-021-1/+4
| | | | | | clear what is happening in this case. llvm-svn: 191860
* Avoid crash in unwinder if ABI isn't availableEd Maste2013-10-021-1/+6
| | | | llvm-svn: 191837
OpenPOWER on IntegriCloud