summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Windows] Use information from the PE32 exceptions directory to construct ↵Aleksandr Urakov2019-10-111-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | unwind plans This patch adds an implementation of unwinding using PE EH info. It allows to get almost ideal call stacks on 64-bit Windows systems (except some epilogue cases, but I believe that they can be fixed with unwind plan disassembly augmentation in the future). To achieve the goal the CallFrameInfo abstraction was made. It is based on the DWARFCallFrameInfo class interface with a few changes to make it less DWARF-specific. To implement the new interface for PECOFF object files the class PECallFrameInfo was written. It uses the next helper classes: - UnwindCodesIterator helps to iterate through UnwindCode structures (and processes chained infos transparently); - EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram; - EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction over the low-level unwind codes and simplifies work with them. It contains only the information that is relevant to unwinding in the unified form. Also the required unwind codes are read from the object file only once with it; - EHProgramRange allows to take a range of EHProgram and to build an unwind row for it. So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges corresponding to every offset in prologue and builds the rows of the resulted unwind plan. The resulted plan covers the whole range of the function except the epilogue. Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola Reviewed By: jasonmolenda Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67347 llvm-svn: 374528
* Unwind: Add a stack scanning mechanism to support win32 unwindingPavel Labath2019-09-271-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Windows unwinding is weird. The unwind rules do not (always) describe the precise layout of the stack, but rather expect the debugger to scan the stack for something which looks like a plausible return address, and the unwind based on that. The reason this works somewhat reliably is because the the unwinder also has access to the frame sizes of the functions on the stack. This allows it (in most cases) to skip function pointers in local variables or function arguments, which could otherwise be mistaken for return addresses. Implementing this kind of unwind mechanism in lldb was a bit challenging because we expect to be able to statically describe (in the UnwindPlan) structure, the layout of the stack for any given instruction. Giving a precise desription of this is not possible, because it requires correlating information from two functions -- the pushed arguments to a function are considered a part of the callers stack frame, and their size needs to be considered when unwinding the caller, but they are only present in the unwind entry of the callee. The callee may end up being in a completely different module, or it may not even be possible to determine it statically (indirect calls). This patch implements this functionality by introducing a couple of new APIs: SymbolFile::GetParameterStackSize - return the amount of stack space taken up by parameters of this function. SymbolFile::GetOwnFrameSize - the size of this function's frame. This excludes the parameters, but includes stuff like local variables and spilled registers. These functions are then used by the unwinder to compute the estimated location of the return address. This address is not always exact, because the stack may contain some additional values -- for instance, if we're getting ready to call a function then the stack will also contain partially set up arguments, but we will not know their size because we haven't called the function yet. For this reason the unwinder will crawl up the stack from the return address position, and look for something that looks like a possible return address. Currently, we assume that something is a valid return address if it ends up pointing to an executable section. All of this logic kicks in when the UnwindPlan sets the value of CFA as "isHeuristicallyDetected", which is also the final new API here. Right now, only SymbolFileBreakpad implements these APIs, but in the future SymbolFilePDB will use them too. Differential Revision: https://reviews.llvm.org/D66638 llvm-svn: 373072
* DWARFExpression: Simplify class interfacePavel Labath2019-08-271-4/+2
| | | | | | | | | | | | | | | | | Summary: The DWARFExpression methods have a lot of arguments. This removes two of them by removing the ability to slice the expression via two offset+size parameters. This is a functionality that it is not always needed, and when it is, we already have a different handy way of slicing a data extractor which we can use instead. Reviewers: JDevlieghere, clayborg Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D66745 llvm-svn: 370027
* Fix PC adjustment in StackFrame::GetSymbolContextJoseph Tremoulet2019-08-021-47/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Update StackFrame::GetSymbolContext to mirror the logic in RegisterContextLLDB::InitializeNonZerothFrame that knows not to do the pc decrement when the given frame is a signal trap handler frame or the parent of one, because the pc may not follow a call in these frames. Accomplish this by adding a behaves_like_zeroth_frame field to lldb_private::StackFrame, set to true for the zeroth frame, for signal handler frames, and for parents of signal handler frames. Also add logic to propagate the signal handler flag from UnwindPlan to the FrameType on the RegisterContextLLDB it generates, and factor out a helper to resolve symbol and address range for an Address now that we need to invoke it in four places. Reviewers: jasonmolenda, clayborg, jfb Reviewed By: jasonmolenda Subscribers: labath, dexonsmith, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64993 llvm-svn: 367691
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-241-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
* Support Linux signal return trampolines in frame initializationJoseph Tremoulet2019-07-191-12/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add __kernel_rt_sigreturn to the list of trap handlers for Linux (it's used as such on aarch64 at least), and __restore_rt as well (used on x86_64). Skip decrement-and-recompute for trap handlers in InitializeNonZerothFrame, as signal dispatch may point the child frame's return address to the start of the return trampoline. Parse the 'S' flag for signal handlers from eh_frame augmentation, and propagate it to the unwind plan. Reviewers: labath, jankratochvil, compnerd, jfb, jasonmolenda Reviewed By: jasonmolenda Subscribers: clayborg, MaskRay, wuzish, nemanjai, kbarton, jrtc27, atanasyan, jsji, javed.absar, kristof.beyls, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D63667 llvm-svn: 366580
* [FuncUnwinders] Use "symbol file" unwind plans for unwindingPavel Labath2019-05-241-6/+8
| | | | | | | | | | | | | | | | | Summary: Previous patch (r360409) introduced the "symbol file unwind plan" concept, but that plan wasn't used for unwinding yet. With this patch, we start to consider the new plan as a possible strategy for both synchronous and asynchronous unwinding. I also add a test that asserts that unwinding via breakpad STACK CFI info works end-to-end. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits, amccarth, markmentovai Differential Revision: https://reviews.llvm.org/D61853 llvm-svn: 361618
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-231-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]] This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information. This is the command I ran and I to fix and format the code base: ``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ``` NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow. NOTE: I know this is a rather large commit but it is a nobrainer in most parts. Reviewers: martong, espindola, shafik, #lldb, JDevlieghere Reviewed By: JDevlieghere Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D61847 llvm-svn: 361484
* RegisterContextLLDB: Push CFA value on DWARF stack when evaluating register ↵Pavel Labath2019-05-071-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | expressions Summary: This behavior is specified in the Section 6.4.2.3 (Register Rule instructions) of the DWARF4 spec. We were not doing that, which meant that any register rule which was relying on the cfa value being there was not evaluated correctly (it was aborted due to "out of bounds" access). I'm not sure how come this wasn't noticed before, but I guess this has something to do with the fact that dwarf unwind expressions are not used very often, and when they are, the situation is so complicated that the CFA is of no use. I noticed this when I started emitting dwarf expressions for the unwind information present in breakpad symbol files. Reviewers: jasonmolenda, clayborg Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D61018 llvm-svn: 360158
* RegisterContextLLDB::GetFullUnwindPlanForFrame has four verboseJason Molenda2019-05-021-18/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | logging messages that are written the same, making it difficult to know for certain which code path was taken based on a logfile. Add some words to make each unique. Right now the ordering for finding a FullUnwindPlan (ignoring fallback unwind plan logic) is 1. If this is a _sigtramp like function, try eh_frame which is hand written on darwin systems to account for finding the saved register context correctly. 2. Ask the DynamicLoader if eh_frame should be preferred for this frame. Some binaries on the system may have hand-written eh_frame and the DynamicLoader is the source for this. (primarily this is for hand-written assembly in the objc runtime, and we tell lldb to trust that for functions in libobjc.dylib.) 3. if 0th frame, use GetUnwindPlanAtNonCallSite plan. 4. GetUnwindPlanAtCallSite {for 0th or any other} 5. GetUnwindPlanAtNonCallSite {now for non-0th frames, only if not from a compiler? hm.} 6. GetUnwindPlanArchitectureDefaultAtFunctionEntry if we're on the first instruction 7. Architectural default unwind plan ABI::CreateDefaultUnwindPlan I'm moving #6 -- DefaultAtFunctionEntry -- up to between #3 and #4, where we're already doing things specific to the zeroth frame. If we're on the zeroth frame and the GetUnwindPlanAtNonCallSite plan has failed for some reason, and we're on the first instruction, we should definitely use DefaultAtFunctionEntry instead of any other unwind plan. If we're trying to step out of some rando function on the system that we couldn't assembly instruction inspect, this is sufficient for us to step out of it. llvm-svn: 359847
* FuncUnwinders: remove "current_offset" from function argumentsPavel Labath2019-04-231-14/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This argument was added back in 2010 (r118882) to support the ability to unwind from functions whose eh_frame entry does not cover the entire range of the function. However, due to the caching happening in FuncUnwinders, this solution is very fragile. FuncUnwinders will cache the plan it got from eh_frame regardless of the value of the current_offset, so our ability to unwind from a given function depended what was the value of "current_offset" the first time that this function was called. Furthermore, since the "image show-unwind" command did not know what's the right offset to pass, this created an unfortunate situation where "image show-unwind" would show no valid plans for a function, even though they were available and being used. In this patch I implement the feature slightly differently. Instead of giving just a base address to the eh_frame unwinder, I give it the entire range we are interested in. Then, I change the unwinder to return the first plan that covers (even partially) that range. This way even a partial plan will be returned, regardless of the address in the function where we are stopped at. This solution is still not 100% correct, as it will not handle a function which is covered by two independent fde entries. However, I don't expect anybody will write this kind of functions, and this wasn't handled by the previous implementation either. If this is ever needed in the future. The eh_frame unwinder can be extended to return "composite" unwind plans created by merging sevelar fde entries. I also create a test which triggers this scenario. As doing this is virtually impossible without hand-written assembly, the test only works on x86 linux. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D60829 llvm-svn: 358964
* Move UnwindTable from ObjectFile to ModulePavel Labath2019-02-141-11/+8
| | | | | | | | | | | | | | | Summary: This is a preparatory step to enable adding extra unwind strategies by symbol file plugins. This has been discussed on the lldb-dev mailing list: <http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>. Reviewers: jasonmolenda, clayborg, espindola Subscribers: lemo, emaste, lldb-commits, arichardson Differential Revision: https://reviews.llvm.org/D58129 llvm-svn: 354033
* Use std::make_shared in LLDB (NFC)Jonas Devlieghere2019-02-111-6/+10
| | | | | | | | | | | Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block. Differential revision: https://reviews.llvm.org/D57990 llvm-svn: 353764
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Simplify Boolean expressionsJonas Devlieghere2018-12-151-17/+9
| | | | | | | | | | | This patch simplifies boolean expressions acorss LLDB. It was generated using clang-tidy with the following command: run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD Differential revision: https://reviews.llvm.org/D55584 llvm-svn: 349215
* [x86] Fix issues with a realigned stack in MSVC compiled applicationsAleksandr Urakov2018-10-301-50/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes issues with a stack realignment. MSVC maintains two frame pointers (`ebx` and `ebp`) for a realigned stack - one is used for access to function parameters, while another is used for access to locals. To support this the patch: - adds an alternative frame pointer (`ebx`); - considers stack realignment instructions (e.g. `and esp, -32`); - along with CFA (Canonical Frame Address) which point to the position next to the saved return address (or to the first parameter on the stack) introduces AFA (Aligned Frame Address) which points to the position of the stack pointer right after realignment. AFA is used for access to registers saved after the realignment (see the test); Here is an example of the code with the realignment: ``` struct __declspec(align(256)) OverAligned { char c; }; void foo(int foo_arg) { OverAligned oa_foo = { 1 }; auto aaa_foo = 1234; } void bar(int bar_arg) { OverAligned oa_bar = { 2 }; auto aaa_bar = 5678; foo(1111); } int main() { bar(2222); return 0; } ``` and here is the `bar` disassembly: ``` push ebx mov ebx, esp sub esp, 8 and esp, -100h add esp, 4 push ebp mov ebp, [ebx+4] mov [esp+4], ebp mov ebp, esp sub esp, 200h mov byte ptr [ebp-200h], 2 mov dword ptr [ebp-4], 5678 push 1111 ; foo_arg call j_?foo@@YAXH@Z ; foo(int) add esp, 4 mov esp, ebp pop ebp mov esp, ebx pop ebx retn ``` Reviewers: labath, zturner, jasonmolenda, stella.stamenova Reviewed By: jasonmolenda Subscribers: abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D53435 llvm-svn: 345577
* Don't type-erase the SymbolContextItem enumeration.Zachary Turner2018-10-251-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When we get the `resolve_scope` parameter from the SB API, it's a `uint32_t`. We then pass it through all of LLDB this way, as a uint32. This is unfortunate, because it means the user of an API never actually knows what they're dealing with. We can call it something like `resolve_scope` and have comments saying "this is a value from the `SymbolContextItem` enumeration, but it makes more sense to just have it actually *be* the correct type in the actual C++ type system to begin with. This way the person reading the code just knows what it is. The reason to use integers instead of enumerations for flags is because when you do bitwise operations on enumerations they get promoted to integers, so it makes it tedious to constantly be casting them back to the enumeration types, so I've introduced a macro to make this happen magically. By writing LLDB_MARK_AS_BITMASK_ENUM after defining an enumeration, it will define overloaded operators so that the returned type will be the original enum. This should address all the mechanical issues surrounding using rich enum types directly. This way, we get a better debugger experience, and new users to the codebase can get more easily acquainted with the codebase because their IDE features can help them understand what the types mean. Differential Revision: https://reviews.llvm.org/D53597 llvm-svn: 345313
* Move RegisterValue,Scalar,State from Core to UtilityPavel Labath2018-08-071-1/+1
| | | | | | | | | | | | | These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-193/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
* Remove the DWARFExpression -> Clang ExpressionParser dependencyTamas Berghammer2017-08-161-4/+4
| | | | | | | | It was completly unused and broke the part of the encapsulation that common code shouldn't depend on specific plugins or language specific features. llvm-svn: 311000
* Fix two places in RegisterContextLLDB::InitializeNonZerothFrame whereJason Molenda2017-06-291-13/+14
| | | | | | | | I'm not running the saved pc through FixCodeAddress as soon as I should. <rdar://problem/30686307> llvm-svn: 306634
* Fix backtrace of noreturn functions situated at the end of a modulePavel Labath2017-06-081-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: When a call instruction is the last instruction in a function, the backtrace PC will point past the end of the function. We already had special code to handle that, but we did not handle the case where the PC ends up outside of the bounds of the module containing the function, which is a situation that occured in TestNoreturnUnwind on android for some arch/compiler combinations. I fix this by adding an argument to Address resolution code which states that we are ok with addresses pointing to the end of a module/section to resolve to that module/section. I create a reproducible test case for this situation by hand-crafting an executable which has a noreturn function at the end of a module. Reviewers: jasonmolenda, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D32022 llvm-svn: 304976
* Rename Error -> Status.Zachary Turner2017-05-121-5/+5
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner2017-03-041-1/+1
| | | | llvm-svn: 296943
* Move Log from Core -> Utility.Zachary Turner2017-03-031-1/+1
| | | | | | | | | All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
* Before returning a pc value for a stack frame,Jason Molenda2017-02-141-3/+21
| | | | | | | run it through the ABI's FixCodeAddress method. <rdar://problem/29711506> llvm-svn: 295025
* Make lldb -Werror clean for -Wstring-conversionDavid Blaikie2017-01-061-8/+4
| | | | | | | | | Also found/fixed one bug identified by this warning in RenderScriptx86ABIFixups.cpp where a string literal was being used in an effort to provide a name for an instruction/register, but was instead being passed as the bool 'isVolatile' parameter. llvm-svn: 291198
* Don't allow direct access to StreamString's internal buffer.Zachary Turner2016-11-161-3/+3
| | | | | | | | | | | | | | | This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-1874/+1830
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Revert r273524, it may have been the cause of a linux testbot failureJason Molenda2016-06-231-1/+1
| | | | | | | | for TestNamespaceLookup.py; didn't see anything obviously wrong so I'll need to look at this more closely before re-committing. (passed OK on macOS ;) llvm-svn: 273531
* Do some minor renames of "Mac OS X" to "macOS".Jason Molenda2016-06-231-1/+1
| | | | | | | | | There's uses of "macosx" that will be more tricky to change, like in triples (e.g. "x86_64-apple-macosx10.11") - for now I'm just updating source comments and strings printed for humans. llvm-svn: 273524
* Some changes to prevent searching down the stack for saved registerJason Molenda2016-05-201-10/+29
| | | | | | | | | | | | | | | | | | | | | | | | values for the pc or return address register. On ios with arm64 and a binary that has multiple functions without individual symbol boundaries, we end up with an assembly profile unwind plan that says lr=<same> - that is, the link register contents are unmodified from the caller's value. This gets the unwinder in a loop. When we're off the 0th frame, we never want to look to a caller for a pc or return-address register value. Add checks to ReadGPRValue and ReadRegister to prevent both the pc and ra register values from recursing. If this causes problems with backtraces on android, let me know or back it out and I'll look into it -- but I think these are straightforward and don't expect problems. <rdar://problem/24610365> llvm-svn: 270162
* Fix unwind failures when PC points beyond the end of a functionUlrich Weigand2016-04-241-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RegisterContextLLDB::InitializeNonZerothFrame already has code to attempt to detect and handle the case where the PC points beyond the end of a function, but there are certain cases where this doesn't work correctly. In fact, there are *two* different places where this detection is attempted, and the failure is in fact a result of an unfortunate interaction between those two separate attempts. First, the ResolveSymbolContextForAddress routine is called with the resolve_tail_call_address flag set to true. This causes the routine to internally accept a PC pointing beyond the end of a function, and still resolving the PC to that function symbol. Second, the InitializeNonZerothFrame routine itself maintains a "decr_pc_and_recompute_addr_range" flag and, if that turns out to be true, itself decrements the PC by one and searches again for a symbol at that new PC value. Both approaches correctly identify the symbol associated with the PC. However, the problem is now that later on, we also need to find the DWARF CFI record associated with the PC. This is done in the RegisterContextLLDB::GetFullUnwindPlanForFrame routine, and uses the "m_current_offset_backed_up_one" member variable. However, that variable only actually contains the PC "backed up by one" if the *second* approach above was taken. If the function was already identified via the first approach above, that member variable is *not* backed up by one but simply points to the original PC. This in turn causes GetEHFrameUnwindPlan to not correctly identify the DWARF CFI record associated with the PC. Now, in many cases, if the first method had to back up the PC by one, we *still* use the second method too, because of this piece of code: // Or if we're in the middle of the stack (and not "above" an asynchronous event like sigtramp), // and our "current" pc is the start of a function... if (m_sym_ctx_valid && GetNextFrame()->m_frame_type != eTrapHandlerFrame && GetNextFrame()->m_frame_type != eDebuggerFrame && addr_range.GetBaseAddress().IsValid() && addr_range.GetBaseAddress().GetSection() == m_current_pc.GetSection() && addr_range.GetBaseAddress().GetOffset() == m_current_pc.GetOffset()) { decr_pc_and_recompute_addr_range = true; } In many cases, when the PC is one beyond the end of the current function, it will indeed then be exactly at the start of the next function. But this is not always the case, e.g. if there happens to be alignment padding between the end of one function and the start of the next. In those cases, we may sucessfully look up the function symbol via ResolveSymbolContextForAddress, but *not* set decr_pc_and_recompute_addr_range, and therefore fail to find the correct DWARF CFI record. A very simple fix for this problem is to just never use the first method. Call ResolveSymbolContextForAddress with resolve_tail_call_address set to false, which will cause it to fail if the PC is beyond the end of the current function; or else, identify the next function if the PC is also at the start of the next function. In either case, we will then set the decr_pc_and_recompute_addr_range variable and back up the PC anyway, but this time also find the correct DWARF CFI. A related problem is that the ResolveSymbolContextForAddress sometimes returns a "symbol" with empty name. This turns out to be an ELF section symbol. Now, usually those get type eSymbolTypeInvalid. However, there is code in ObjectFileELF::ParseSymbols that tries to change the type of invalid symbols to eSymbolTypeCode or eSymbolTypeData if the symbol lies within the code or data section. Unfortunately, this check also hits the symbol for the code section itself, which is then marked as eSymbolTypeCode. While the size of the section symbol is 0 according to the ELF file, LLDB considers this size invalid and attempts to figure out the "correct" size. Depending on how this goes, we may end up with a symbol that overlays part of the code section, even outside areas covered by real function symbols. Therefore, if we call ResolveSymbolContextForAddress with PC pointing beyond the end of a function, we may get this bogus section symbol. This again means InitializeNonZerothFrame thinks we have a valid PC, but then we don't find any unwind info for it. The fix for this problem is me to simply always leave ELF section symbols as type eSymbolTypeInvalid. Differential Revision: http://reviews.llvm.org/D18975 llvm-svn: 267363
* Add new ABI callback to provide fallback unwind register locationsUlrich Weigand2016-04-141-26/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the UnwindPlan did not identify how to unwind the stack pointer register, LLDB currently assumes it can determine to caller's SP from the current frame's CFA. This is true on most platforms where CFA is by definition equal to the incoming SP at function entry. However, on the s390x target, we instead define the CFA to equal the incoming SP plus an offset of 160 bytes. This is because our ABI defines that the caller has to provide a register save area of size 160 bytes. This area is allocated by the caller, but is considered part of the callee's stack frame, and therefore the CFA is defined as pointing to the top of this area. In order to make this work on s390x, this patch introduces a new ABI callback GetFallbackRegisterLocation that provides platform- specific fallback register locations for unwinding. The existing code to handle SP unwinding as well as volatile registers is moved into the default implementation of that ABI callback, to allow targets where that implementation is incorrect to override it. This patch in itself is a no-op for all existing platforms. But it is a pre-requisite for adding s390x support. Differential Revision: http://reviews.llvm.org/D18977 llvm-svn: 266307
* Add support for DW_OP_push_object_address in dwarf expressionsTamas Berghammer2016-02-261-2/+2
| | | | | | | | | Additionally fix the type of some dwarf expression where we had a confusion between scalar and load address types after a dereference. Differential revision: http://reviews.llvm.org/D17604 llvm-svn: 262014
* Fix for TestNoreturnUnwind.py on i386Ravitheja Addepally2016-01-121-3/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The testcase TestNoreturnUnwind.py was failing because the unwind from the vdso library was not successful for clang compiler while it was passing for gcc. It was passing for gcc since the unwind plan used was the assembly plan and the ebp register was set by the main function in case of gcc and was not used by the functions in the call flow to the vdso, whereas clang did not emit assembly prologue for main and so the assembly unwind was failing. Normally in case of failure of assembly unwind, lldb switches to EH CFI frame based unwinding, but this was not happening for the first frame. This patch tries to fix this behaviour by falling to EH CFI frame based unwinding in case of assembly unwind failure even for the first frame. The test is still marked as XFAIL since it relys on the fix of another bug. Reviewers: lldb-commits, jingham, zturner, tberghammer, jasonmolenda Subscribers: jasonmolenda Differential Revision: http://reviews.llvm.org/D15046 llvm-svn: 257465
* 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
OpenPOWER on IntegriCloud