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

[Rafal Jaworowski]

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.

Rafal