Walking through the Call Stack

The heuristic method is quick but produces lots of false positives. -Another option is to manually reconstitute the call stack from the memory dump. -This is relatively easy for debug builds because GCC uses R11 as a frame -pointer (FP) and generates the same prologue/epilogue for every -function.

For release builds, there is no generic solution. It is necessary -to check the generated assembler code as there is no standard prologue/epilogue -and R11 is not used as frame pointer.

A typical prologue for a debug ARM function looks like this:

mov     ip, sp
stmfd   sp!, {fp, ip, lr, pc}
sub     fp, ip, #4     /* FP now points to base of stack frame */
sub     sp, sp, #16    /* space for local variables */

noting that: SP = R13, FP = R11, IP -= R12, LR = R14, and PC = R15.

This code creates the following stack frame:

Looking at the example session listed in when -tracing through the stack heuristically. in which the crash is due to a panic, the FP value is the -R11 value; this is 0x6571de70. This gives us the innermost stack -frame:

6571de64:   e8 de 71 65 <------------- pointer to previous stack frame
            74 de 71 65
            74 fb 16 f8 <------------- Saved return address
            88 28 03 f8 <------------- FP points to this word

Looking up the saved return address, 0xf816fb74, in -the symbol file shows that the current function was called from -DDmaChannel::DoCreate().

f816fb50 0198 DDmaTestChannel::DoCreate(int, TDesC8 const *, TVersion const &)
f816fce8 007c DDmaTestChannel::~DDmaTestChannel(void)
f816fd64 0294 DDmaTestChannel::Request(int, void *, void *)

Using the pointer to the previous stack frame saved into the -current frame, we can decode the next frame:

6571ded4:   1c c4 03 64
            f8 02 00 64
            10 df 71 65 <------------- pointer to previous stack frame
            ec de 71 65

6571dee4:   84 da 01 f8 <------------- saved return address
            5c fb 16 f8 <------------- start of second stack frame
            00 4e 40 00
            00 00 00 00

Looking up the saved return address, 0xf801da84, in -the symbol file shows that DDmaTestChannel::DoCreate() was called -from DLogicalDevice::ChannelCreate().

f801d9b4 00f8 DLogicalDevice::ChannelCreate(DLogicalChannelBase *&, TChannelCreateInfo &)
f801daac 01b8 ExecHandler::ChannelCreate(TDesC8 const &, TChannelCreateInfo &, int)
f801dc64 00e4 ExecHandler::ChannelRequest(DLogicalChannelBase *, int, void *, void *)

And here is the third stack frame:

6571df04:   d4 df 71 65 <------------- pointer to previous stack frame
            14 df 71 65
            e0 db 01 f8 <------------- saved return address
            c0 d9 01 f8 <------------- start of third stack frame

So DLogicalDevice::ChannelCreate() was called from -ExecHandler::ChannelCreate().

Note that this mechanical way of walking the stack is valid only -for debug functions. For release functions, it is necessary to study the code -generated by the compiler.

For completness, this is a typical prologue for a debug THUMB -function:

push    { r7, lr }
sub     sp, #28
add     r7, sp, #12 /* R7 is THUMB frame pointer */

and this creates the following stack frame:

A call stack can mix ARM and THUMB frames. Odd return addresses are -used for THUMB code and even ones for ARM code.

- -

The heuristic method is quick but produces lots of false positives. +Another option is to manually reconstitute the call stack from the memory dump. +This is relatively easy for debug builds because GCC uses R11 as a frame +pointer (FP) and generates the same prologue/epilogue for every +function.

For release builds, there is no generic solution. It is necessary +to check the generated assembler code as there is no standard prologue/epilogue +and R11 is not used as frame pointer.

A typical prologue for a debug ARM function looks like this:

mov     ip, sp
stmfd   sp!, {fp, ip, lr, pc}
sub     fp, ip, #4     /* FP now points to base of stack frame */
sub     sp, sp, #16    /* space for local variables */

noting that: SP = R13, FP = R11, IP += R12, LR = R14, and PC = R15.

This code creates the following stack frame:

Looking at the example session listed in when +tracing through the stack heuristically. in which the crash is due to a panic, the FP value is the +R11 value; this is 0x6571de70. This gives us the innermost stack +frame:

Looking up the saved return address, 0xf816fb74, in +the symbol file shows that the current function was called from +DDmaChannel::DoCreate().

f816fb50 0198 DDmaTestChannel::DoCreate(int, TDesC8 const *, TVersion const &)
f816fce8 007c DDmaTestChannel::~DDmaTestChannel(void)
f816fd64 0294 DDmaTestChannel::Request(int, void *, void *)

Using the pointer to the previous stack frame saved into the +current frame, we can decode the next frame:

Looking up the saved return address, 0xf801da84, in +the symbol file shows that DDmaTestChannel::DoCreate() was called +from DLogicalDevice::ChannelCreate().

And here is the third stack frame:

So DLogicalDevice::ChannelCreate() was called from +ExecHandler::ChannelCreate().

Note that this mechanical way of walking the stack is valid only +for debug functions. For release functions, it is necessary to study the code +generated by the compiler.

For completness, this is a typical prologue for a debug THUMB +function:

push    { r7, lr }
sub     sp, #28
add     r7, sp, #12 /* R7 is THUMB frame pointer */

and this creates the following stack frame:

A call stack can mix ARM and THUMB frames. Odd return addresses are +used for THUMB code and even ones for ARM code.

+ +

Walking through the Call Stack

Related tasks

Walking through the Call Stack

Related tasks