| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Review URL: http://breakpad.appspot.com/316001
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@871 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
| |
Review URL: http://breakpad.appspot.com/314001
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@869 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
| |
R=jimb at http://breakpad.appspot.com/206001/show
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@704 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch allows the Breakpad minidump processor to use data from
STACK CFI records to generate stack traces for the ARM processor.
In the symbol dumper, we need a table mapping DWARF CFI register
numbers to their names: STACK CFI records refer to registers by name.
In the processor, we expand StackwalkerARM::GetCallerFrame to see if
there are STACK CFI records covering the callee, and then use those to
recover the caller's register values.
There's no good reason the ARM walker couldn't use the SimpleCFIWalker
interface declared in cfi_frame_info.h. Unfortunately, that interface
assumes that one can map register names to member pointers of the raw
context type, while MDRawContextARM uses an array to hold the
registers' values: C++ pointer-to-member types can't refer to elements
of member arrays. So we have to write out SimpleCFIWalker::FindCallerRegisters
in StackwalkerARM::GetCallerFrame.
We define enum MDARMRegisterNumbers in minidump_cpu_arm.h, for
convenience in referring to certain ARM registers with dedicated
purposes, like the stack pointer and the PC.
We define validity flags in StackFrameARM for all the registers, since
CFI could theoretically recover any of them. In the same vein, we
expand minidump_stackwalk.cc to print the values of all valid
callee-saves registers in the context --- and use the proper names for
special-purpose registers.
We provide unit tests that give full code and branch coverage (with
minor exceptions). We add a testing interface to StackwalkerARM that
allows us to create context frames that lack some register values.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@553 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
| |
We've gotten mixed advice from the lawyery types about whether this
matters. But it's easy enough to do.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@517 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment, the StackWalker GetCallerFrame member function expects
a vector of WindowsFrameInfo structures, even though WindowsFrameInfo
is only used or useful on one one implementation (StackWalkerX86).
This patch changes StackWalker::GetCallerFrame to no longer expect the
WindowsFrameInfo structures, and changes all implementations to match.
In particular, StackWalkerX86 is changed to find the WindowsFrameInfo
data itself, and store a pointer to whatever it got in the StackFrame
object itself (which is really a StackFrameX86).
To allow GetCallerFrame implementations to look up stack walking data,
StackWalker::resolver_ needs to be made protected, not private.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@491 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'WindowsFrameInfo'.
Also, rename stack_frame_info.h to windows_frame_info.h.
If it seems odd to have functions like FillSourceLineInfo returning
Windows-specific data structures... well, it is! This patch just makes
it more obvious what's going on.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@471 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@454 4c0a9323-5329-0410-9bdc-e9ce6186880e
|