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

From: Bruce Evans (bde_at_zeta.org.au)
Date: 06/13/03

  • Next message: John-Mark Gurney: "Re: pci probing "fixed" (was Re: PCI bus numbering and orphaned devices)"
    Date: Fri, 13 Jun 2003 09:34:31 +1000 (EST)
    To: Tim Robbins <tjr@freebsd.org>
    
    

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


  • Next message: John-Mark Gurney: "Re: pci probing "fixed" (was Re: PCI bus numbering and orphaned devices)"

    Relevant Pages

    • Re: Apparent i386 alloca.S bug (was: adsl/pppoe no longerconnecting on 5.1)
      ... This method of passing args is completely ... >>with any implementation of the libc alloca like the current one. ... bad memory or program bugs. ... The fix for the alloca bug is just to not use this file for gcc. ...
      (freebsd-current)
    • Apparent i386 alloca.S bug (was: adsl/pppoe no longer connecting on 5.1)
      ... >> builtin alloca() until we figure out how to fix the one in libc. ... >prepares space for storing the args by subtracting from %esp. ... >clobbers the allocated space when it stores the args. ...
      (freebsd-current)
    • Re: Any explanations
      ... movl %esp, %ebp ... xorl %eax, %eax ... can only assume that alloca() or the secondary mainconsumes a stack ...
      (comp.lang.asm.x86)
    • Re: Any explanations
      ... movl %esp, %ebp ... xorl %eax, %eax ... I guess alloca allocate some memory? ...
      (comp.lang.asm.x86)
    • Re: Implicit int
      ... implementations, it might be worth adding on that basis. ... adjust the stack pointer and let the program crash when it tries to use ... too much of the allocated space; ... VLAs were intended to provide all the advantages of alloca() without the ...
      (comp.std.c)