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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
