gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
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
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.
More information about the freebsd-hackers