GNU Arm Embedded Toolchain

init stack frame register

Asked by Martin Velek

Hello,

with the recent version of arm-none-eabi-gcc version 4.8.3 20140228 (release) and FreeRTOS v8.0.0 I am getting stucked during debugging on Cortex - M3 core within Eclipse.

My GDB server (segger) shows me that there is an attempt to read from undefined memory after halting the programm. It is caused by trying to read data from the stack frame (e.g. info stack command). Somewhere in the deep, the stack frame pointer has random value and the gdb generates a read request with a random address.

How should I correctly initialize the stack to tell gdb that it should stop to read because there is not any history? Currently I am using LR = 0 (in pxPortInitialiseStack function) but this leads to read from 0x0000000. GDB stops here but still generates request to read from address 0x0000000. (it would be fine if the MPU allows reading from 0x0000000 which is not my case).

Martin

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
Martin Velek
Solved:
Last query:
Last reply:
Revision history for this message
Joey Ye (jinyun-ye) said : 		#1

Please try to enclose your startup function with this, and let me know if it works
    .fnstart

....
    .cantunwind
    .fnen

Revision history for this message
Joey Ye (jinyun-ye) said : 		#2

For previous comment, these directives apply on assembly code only.

Revision history for this message
Martin Velek (martin-velek) said : 		#3

Hi,

thank You for helping me. Unfortunately my startup function is pure C function, static void task_startup(void * param). I cannot set even the naked attribute because of "void * param". The FreeRTOS scheduler initializes the stack and sets r0 so I can use it (param) later on. To the PC it written the address of task_startup. In SVC handler the PSP is modified to point to the initialized stack and control is passed to task_startup.
I have thought that the debugger takes the depth from stack frame register but it seems it is driven from the source code, because the main function has @ args = 0, pretend = 0, frame = 0 in asm listing.

I should redefine the question, what kind of function attribute should I use stop stack unwinding?

Best
Martin

Revision history for this message
Martin Velek (martin-velek) said : 		#4

I have created a veneer to overcome the impossibility of doing it in C.

static void task_startup_veneer(void *aParams) __attribute__((naked,noreturn));
static void task_startup_veneer(void *aParams)
{
 __asm volatile ("bl task_startup\n");
 __asm volatile ("b .\n");
}

The backtrace stops here with "Backtrace stopped: previous frame identical to this frame (corrupt stack?)" which is better than reading from forbidden/non-existent memory.

Thanks for pointing me out.

Best
Martin