Date: Fri, 9 Dec 2011 20:15:50 +0200 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: Rafal Jaworowski <raj@semihalf.com> Cc: freebsd-hackers@freebsd.org, mdf@freebsd.org, Nathan Whitehorn <nwhitehorn@freebsd.org>, Arnaud Lacombe <lacombar@gmail.com>, Piotr Nowak <pn@semihalf.com> Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 Message-ID: <20111209181550.GA3555@reks> In-Reply-To: <6D023449-EDEA-4B1C-975D-54AA2F4328CE@semihalf.com> References: <20111119100150.GA1560@reks> <CACqU3MXf%2BsbTpZMbqugmMKKb1BEbp6sNzeTkXfvnQtZ1E4ukEA@mail.gmail.com> <BA73AB23-650A-4241-BBAC-BA01BD372AA3@semihalf.com> <20111208090159.GA1924@cq1> <4EE0EB8C.7050800@freebsd.org> <6D023449-EDEA-4B1C-975D-54AA2F4328CE@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111209181550.GA3555>