aboutsummaryrefslogtreecommitdiff
path: root/src/processor/stackwalker_arm64.cc
Commit message (Collapse)AuthorAgeFilesLines
* fix pointer style to match the style guideMike Frysinger2020-07-151-4/+4
| | | | | | | | | | We do this in a lot of places, but we're inconsistent. Normalize the code to the Google C++ style guide. Change-Id: Ic2aceab661ce8f6b993dda21b1cdf5d2198dcbbf Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2262932 Reviewed-by: Sterling Augustine <saugustine@google.com> Reviewed-by: Mark Mentovai <mark@chromium.org>
* arm64: recover register X30(LR) when fallback to frame pointer unwinderSim Sun2020-01-211-0/+39
| | | | | | | | | | | | | Stackwalk can't recover caller's register X30($LR) value by STACK CFI info. This will lead unwinding stop immediately when fallback to frame pointer unwinder. This PR will use try to use second last frame to recover register X30($LR) by frame pointer. And we will give up correction if STACK CFI info doesn't agree with frame pointer info. Bug: https://bugs.chromium.org/p/google-breakpad/issues/detail?id=808 Change-Id: I50649e3398e268b02ff297e83db21d05705c2a2d Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1992641 Reviewed-by: Joshua Peraza <jperaza@chromium.org>
* arm64: strip PACs from link register valuesJoshua Peraza2019-07-231-1/+26
| | | | | | | | | | | | | | | | | | | | | | Pointer authentication codes are used to validate pointers against accidental or malicious modification by storing a hash of the address and a secret value in the pointer's unused, upper bits. The exact bits used may vary by implementation and depend on the size of the virtual address space of the target system, and whether other tagged pointer features are in use. Apple has implemented PACs in the Apple A12. https://developer.apple.com/documentation/security/preparing_your_app_to_work_with_pointer_authentication The documented method of stripping PACs from a pointer is to call ptrauth_strip(), which ultimately emits an `xpaci` instruction, but this option isn't available to the Breakpad processor not running on the device. Instead, this patch selects likely address bits from link register values by examining the address range of loaded modules. Change-Id: I054bd1a03605719937fc85dcc8d8b9fe927f44be Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1713650 Reviewed-by: Mark Mentovai <mark@chromium.org>
* Define and use a a new MDRawContextARM64Joshua Peraza2018-08-011-1/+1
| | | | | | | | | | | This struct matches the layout defined by Microsoft and replaces Breakpad's MDRawContextARM64_Old. This CL updates the processor to understand either the old or new structs, but clients continue to write the old structs. Change-Id: I8dedd9ddb2ec083b802723b9ac87beb18d98edbd Reviewed-on: https://chromium-review.googlesource.com/1155938 Reviewed-by: Mark Mentovai <mark@chromium.org>
* Rename MDRawContextARM64 and its context flagsJoshua Peraza2018-08-011-1/+1
| | | | | | | | | | This makes way for the addition of a struct matching Microsoft's layout for ARM64. Change-Id: I115f25290863e7438852691d1ec3c9324a42f7a5 Reviewed-on: https://chromium-review.googlesource.com/1152158 Reviewed-by: Mark Mentovai <mark@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org>
* Handle very large stack tracesLeonard Mosescu2017-07-121-9/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main motivation for this change is to handle very large stack traces, normally the result of infinite recursion. This part is actually fairly simple, relaxing a few self-imposed limits on how many frames we can unwind and the max size for stack memory. Relaxing these limits requires stricter and more consistent checks for stack unwinding. There are a number of unwinding invariants that apply to all the platforms: 1. stack pointer (and frame pointer) must be within the stack memory (frame pointer, if preset, must point to the right frame too) 2. unwinding must monotonically increase SP (except for the first frame unwind, this must be a strict increase) 3. Instruction pointer (return address) must point to a valid location 4. stack pointer (and frame pointer) must be appropriately aligned This change is focused on 2), which is enough to guarantee that the unwinding doesn't get stuck in an infinite loop. 1) is implicitly validated part of accessing the stack memory (explicit checks might be nice though). 4) is ABI specific and while it may be valuable in catching suspicious frames is not in the scope of this change. 3) is also an interesting check but thanks to just-in-time compilation it's more complex than just calling StackWalker::InstructionAddressSeemsValid() and we don't want to drop parts of the callstack due to an overly conservative check. Bug: chromium:735989 Change-Id: I9aaba77c7fd028942d77c87d51b5e6f94e136ddd Reviewed-on: https://chromium-review.googlesource.com/563771 Reviewed-by: Mark Mentovai <mark@chromium.org> Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
* Add support for CFI based stack walking on Arm64.rmcilroy@chromium.org2014-05-061-2/+71
| | | | | | | | | | | | This CL adds CFI based stack walking support for Arm64 to BreakPad along with unit tests. The Arm64 CFI stack walker is based on the Arm CFI stack walker BUG=367367,335641,354405 R=blundell@chromium.org, mark@chromium.org Review URL: https://breakpad.appspot.com/1664002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1325 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Process minidumps generated on ARM64 in iOS apps.mark@chromium.org2013-11-231-0/+209
Patch by Colin Blundell <blundell@chromium.org> BUG=542 Review URL: https://breakpad.appspot.com/704002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1236 4c0a9323-5329-0410-9bdc-e9ce6186880e