## 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.

##### Related tasks

- General Points
- Finding the Stack
- Tracing through the Call Stack Heuristically