Commit graph

5 commits

Author SHA1 Message Date
Joshua Peraza 88d8114fda Define and use a a new MDRawContextARM64
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>
2018-08-01 19:27:25 +00:00
Joshua Peraza 627ef0cb9c Rename MDRawContextARM64 and its context flags
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>
2018-08-01 19:26:38 +00:00
Leonard Mosescu 01431c2f61 Handle very large stack traces
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>
2017-07-12 17:53:15 +00:00
rmcilroy@chromium.org a789d1d26b Add support for CFI based stack walking on Arm64.
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
2014-05-06 09:18:30 +00:00
mark@chromium.org e9165f4353 Process minidumps generated on ARM64 in iOS apps.
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
2013-11-23 01:45:20 +00:00