gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64

Gleb Kurtsou gleb.kurtsou at gmail.com
Fri Dec 9 18:15:51 UTC 2011


On (09/12/2011 16:15), Rafal Jaworowski wrote:
> 
> On 2011-12-08, at 17:53, Nathan Whitehorn wrote:
> 
> > On 12/08/11 03:01, Piotr Nowak wrote:
> >> We're working on PowerPC target using GCC 4.2.1
> >> and FreeBSD 6.1. It seems like we have similar
> >> problem. In our case GCC sometimes very unfortunately
> >> optimize code with -fno-omit-frame-pointer.
> >> 
> >> Example shown below covers file sys/powerc/booke/pmap.c
> >> and function pmap_kenter. If we disassemble kernel binary
> >> we have:
> >> 
> >> c019998c:   4b ec 6a ed     bl      c0060478<_mtx_unlock_spin_flags>
> >> c0199990:   81 61 00 00     lwz     r11,0(r1)
> >> c0199994:   80 0b 00 04     lwz     r0,4(r11)
> >> c0199998:   7d 61 5b 78     mr      r1,r11
> >> c019999c:   82 ab ff d4     lwz     r21,-44(r11)
> >> c01999a0:   7c 08 03 a6     mtlr    r0
> >> c01999a4:   82 cb ff d8     lwz     r22,-40(r11)
> >> c01999a8:   82 eb ff dc     lwz     r23,-36(r11)
> >> c01999ac:   83 0b ff e0     lwz     r24,-32(r11)
> >> c01999b0:   83 2b ff e4     lwz     r25,-28(r11)
> >> c01999b4:   83 4b ff e8     lwz     r26,-24(r11)
> >> c01999b8:   83 6b ff ec     lwz     r27,-20(r11)
> >> 
> >> As you can see stack pointer on R1 is being updated
> >> before stashed data were pulled off stack. (mr r1,r11)
> >> As a result of this we have chance to get crash when
> >> any interrupt hit shortly after stack pointer update.
> >> The interrupt prologue will override not yet pulled off
> >> pmap_kenter function data.
> >> 
> >> The problem occures only with -fno-omit-frame-pointer
> >> and not every branch returns are beeing corrupted.
> >> 
> >> Do you think this issue may be somehow related to yours?
> >> Are there any patches/solutions to fix it?
> > 
> > Should we turn off -fno-omit-frame-frame-pointer on PPC then? It's enabled in default kernel builds.
> 
> I think that's a good idea. Even though we have managed to trigger
> this only in rare cases, the problem is real and the code generated is
> broken i.e. leads to corruption and panics.

-fno-omit-frame-pointer is there for kernel debugger to be able to
generate backtraces.

Hacking long abandoned gcc version won't get us far either. IMO we'd
better concentrate on external toolchain support and clang.

I wasn't able to come up with a small test case for the problem month
ago, I'll try again once I have free time.

> 
> Rafal
> 


More information about the freebsd-hackers mailing list