Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    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 
    __builtin_return_address()
    : 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?