aboutsummaryrefslogtreecommitdiff
path: root/src/processor/stackwalker_arm64.cc
Commit message (Collapse)AuthorAgeFilesLines
* 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