Date: Tue, 9 Dec 2003 20:57:13 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Scott Kissel <00civic@comcast.net> Cc: freebsd-current@freebsd.org Subject: Re: Apparent i386 alloca.S bug (was: adsl/pppoe no longerconnecting on 5.1) Message-ID: <20031209205644.X4462@gamplex.bde.org> In-Reply-To: <20031209011442.C6926@gamplex.bde.org> References: <000501c3bd74$a73748a0$6701a8c0@Scratch> <20031208233846.N6390@gamplex.bde.org> <20031209011442.C6926@gamplex.bde.org>
index | next in thread | previous in thread | raw e-mail
[Resending after bounce] On Mon, 8 Dec 2003, Scott Kissel wrote: > On Thu, 12 Jun 2003, Tim Robbins wrote: > > >> On Thu, Jun 12, 2003 at 06:29:44PM +1000, Tim Robbins wrote: > >> > >> > Here's a test program for the i386 alloca() bug. Compile with > -std=gnu89 (or > >> > no -std option) and it works fine. Compile with -std=c99 or > -std=c89 and it > >> > breaks like this: > >> > > >> > corruption: 05 should be 0xcc at offset 0 > >> > corruption: 00 should be 0xcc at offset 1 > >> > corruption: 00 should be 0xcc at offset 2 > >> > corruption: 00 should be 0xcc at offset 3 > >> > > >> > Interestingly, gcc -std=c89 on FreeBSD 4.8 doesn't trigger the bug. > >> > >> I should mention that you need to compile with -march=pentiumpro to > trigger > >> the bug. It's related to the way gcc 3 uses "movl x,y(%esp)" instead > of > >> "pushl x" when passing arguments to a function. I suggest backing out > the > >> commit that made CSTD=c99 the default, so that we go back to using > gcc's > >> builtin alloca() until we figure out how to fix the one in libc. > > >I understand this now. This method of passing args is completely > incompatible > >with any implementation of the libc alloca like the current one. gcc > >prepares space for storing the args by subtracting from %esp. Then > >the libc alloca() points %esp to the allocated space, but gcc thinks > that > >%esp still points to the space that it has reserved for the args, so it > >clobbers the allocated space when it stores the args. > > > >BTW, the optimization of using "movl x,y(%esp)" instead of "pushl x" > >has the following benefits and costs: > > > >pentiumpro-like machine (old Celeron): +26% > > (4.05 seconds reduced to 2.99 seconds) > >pentiumpro-like machine (PIII (freefall)): +25% > > (1.82 seconds reduced to 1.37 seconds) > >AthlonXP: -45% > > (0.58 seconds increaded to 0.84 seconds) > > > >The times are for 10^8 calls to somefunc(1, 2, 3, 4, 5) in a loop. Oops, these numbers are backwards for the AthlonXP, which is just as well since the movel optimization is used for -march=athlonXP. > Sorry for bringing up an old message but I received a seg fault core > dump when performing a make buildworld after cvsuping. The exit was at: > cc -O -pipe -march=pentium2 -I/usr/src/lib/libc/include > -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 > -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 > -I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale > -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP > -DHESIOD -Wsystem-headers -Werror -c > /usr/src/lib/libc/i386/gen/alloca.S > Segmentation fault (core dumped) > *** Error code 139 > > In an attempt to search why it's happening, I ran across these messages > and couldn't help but wonder if there was a fix or work around ever > figured out. While I am somewhat understanding what is being said in the > above messages, I wasn't sure if I was supposed to edit the alloca.S > file to resolve the issue, and how exactly to go about making changes in > that file. For reference, here's what it looks like: I think this is an unrelated problem. Most "Segmentation fault" are from bad memory or program bugs. > > #if !defined(__GNUC__) && !defined(__INTEL_COMPILER) > #error Please add alloca support for this compiler on FreeBSD. The fix for the alloca bug is just to not use this file for gcc. This should happen automatically. Brucehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031209205644.X4462>