Hi everyone,
I am working on an S32K3 MCU using the Green Hills Software (GHS) compiler, and I am implementing a DumpCallStack function.
To obtain the frame pointer (FP), I am using the following inline assembly:
__asm volatile ("mov %0, r7" : "=r" (locals.fp));
However, the value I get for locals.fp is 0x02B1, which does not appear to be a valid frame pointer. It is not aligned and does not point to a valid stack location, so the call stack cannot be unwound correctly.
My questions are:
What is the correct way to obtain the current frame pointer when using the GHS compiler on the S32K3 (Arm Cortex-M7)?
Does the GHS compiler always use R7 as the frame pointer, or can it omit the frame pointer or use another register depending on the optimization level?
Are there any compiler options that must be enabled to preserve the frame pointer for stack unwinding?
Is there a recommended GHS-specific API or intrinsic for retrieving the frame pointer instead of using inline assembly?
If anyone has implemented stack unwinding or a DumpCallStack function with the GHS compiler on S32K3, I would appreciate any guidance or examples.
Thank you!
Hi,
I would not assume that R7 is always used as the frame pointer. Depending on the GHS version, optimization level, and compiler options, the compiler may use a different register or omit the frame pointer entirely and use R7 as a general-purpose register. The value 0x02B1 suggests that R7 might not be acting as a frame pointer in your build.
Please check the generated assembly and verify whether GHS is creating frame records at all. If frame pointers are enabled, you should see a consistent function prologue saving/restoring the frame pointer; otherwise stack unwinding based on R7/R11 will not be reliable.
Since this is primarily a compiler-specific question, I would also recommend contacting Green Hills Software support. They can advise on:
They are best positioned to provide guidance specific to your compiler version and settings.
BR, Petr