Re: Apparent i386 alloca.S bug (was: adsl/pppoe no longerconnecting on 5.1)

[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.

Bruce