Forum Discussion
Gcc4 Frame Pointer Issue
I've been trying to write some code in an MPU exception handler to trap and dump the call stack when an intermittent exception occurs in our system and am pretty sure I've found a bug in the latest Gcc4 compiler that ships with Quartus 10.0. I haven't tried it on 10.1 as yet.
It seems under gcc4 the frame pointer is not calcuated correctly in all cases. Here's the generated asm code from gcc3 (10.0) addi sp,sp,-120 stw ra,116(sp) stw fp,112(sp) stw r16,108(sp) stw r17,104(sp) stw r18,100(sp) stw r19,96(sp) stw r20,92(sp) addi fp,sp,112 And the corresponding code from Gcc4 addi sp,sp,-116 stw ra,112(sp) stw fp,108(sp) stw r19,104(sp) stw r18,100(sp) stw r17,96(sp) stw r16,92(sp) addi fp,sp,92 Under Gcc4 the frame pointer is not pointing to the correct location as documented in the Nios II Processor Reference Handbook Section II-7 Stacks. You can see the difference in the addi fp,sp,xx instruction. Gcc3 does seem to do it right. Also I've found that the __builtin_return_address() function does not work for Gcc4. Any value greater than >0 under Gcc4 returns 0 for the address. Rebuild under Gcc3 and it works fine. Can any one shed some light on this. If it's not a bug how should the call stack be walked now? The following code works under gcc3, fails under gcc4. struct stack_frame { struct stack_frame* next; void* ret; }; struct stack_frame* fp; __asm ("mov %0, fp" : "=r" (fp) ); alt_u32 cnt = 0; while(fp && (cnt < 10)) { isr_printf("%x: fp(%x) pfp(%x) ra(%x)\n", cnt, fp, fp->next, fp->ret); fp = fp->next; cnt++; } ; :cry:18 Replies
- Altera_Forum
Honored Contributor
That is a bug, the frame pointers should point to each other.
- Altera_Forum
Honored Contributor
I am facing the same issue -- the compiler bug is preventing me from implementing a backtrace function for our system. I believe we're using gcc-4.1.2. Any resolution or workarounds for this issue?
Thanks for any help. - Altera_Forum
Honored Contributor
Possibly dumb question: is it a bug or is it a result of frame pointer optimization?
Would compiling with -fno-omit-frame-pointer help? - Altera_Forum
Honored Contributor
It appears to be a real bug. I've already chased -fno-omit-frame-pointer quite a bit. Also turns out that -O1, or just about anything other than -O0, will also turn off frame pointers. I think I have that part nailed down, but it still seems that half the functions have the correct prologue, while others don't. I'm getting the exact same results as the first post in this thread.
- Altera_Forum
Honored Contributor
You won't get a backtrace without frame pointers (well not trivially).
There are some techniques that do work without having to look at the dwarf (or whatever the flavour of the month is) stack offset data. If you aren't in a function that doesn't return, it is a SMOP to follow instructions forwards keeping track of %sp until you hit a return instruction. - Altera_Forum
Honored Contributor
Sigh.
2yrs later and with Quartus 12.1 seems to still have the problem that I report in Jan 2011. We've been running with gcc3 for an extended time period but need to update and the Quartus 12.1 installation seems to have removed gcc3 support. Anyone got a work around to the problem? jcn - Altera_Forum
Honored Contributor
Build gcc from the sources.
Or you could just do what the linux kernel does for tracebacks... Just print every word from the stack that points into the code space. (You could look at the instruction at the call site to supress some incorrect entries.) You might also find that it is actually a simple bug in the gcc code for nios - possibly a change that should have been done for gcc4, but wasn't. The gcc4 and gcc3 nios support files are almost identical (well, were last time I looked). Trouble is, fixing gcc either involves a lot of knowledge, or some blind faith! - Altera_Forum
Honored Contributor
G'day dsl,
Build gcc from source is last on my list :) The idea to print every word seems like a good workaround. - Altera_Forum
Honored Contributor
The build instructions on the wiki make it easy (fixing it is more difficult).
More useful if you don't want you C compilations be tied to the Altera IDE. - Altera_Forum
Honored Contributor
Any news concerning this frame pointer issue?
I am trying to store/dump a backtrace in case of an exception in a NiosII system (without MPU) with ACDS 13.01 sp1 (gcc version 4.5.3). My observation matches exactly the OPs description. The compiler seems to calculate the frame pointer correctly as long as the called functions do not hold a lot of local variables. But with a more complex chain of function calls, the fp points somewhere near the stack pointer but NOT to the actual back link. As for the
: still the same in gcc 4.5.3. Does anyone know if this behaviour is still the same with the new compiler in Quartus/Nios 13.1?__builtin_return_address()