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

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.

Bruce