Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 01 Dec 2003 22:28:21 -0800
From:      Peter Wemm <peter@wemm.org>
To:        James Van Artsdalen <james-freebsd-amd64@jrv.org>
Cc:        freebsd-amd64@freebsd.org
Subject:   Re: Varargs issues 
Message-ID:  <20031202062821.574D32A7EA@canning.wemm.org>
In-Reply-To: <200312020557.hB25vdZF079987@bigtex.jrv.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
James Van Artsdalen wrote:
> gcc will never generate code referencing memory at addresses less than
> the current value of SP.  Is there much userland code that does this?
> I'd almost rather let the signal handler trash these areas so such code
> can be found and fixed.

Sorry, its part of the amd64 unix ABI, and gcc does indeed use it.

Here's some totally bogus code to demonstrate it...  Its convoluted to make sure
the optimizer doesn't remove the stack usage:

int
bar(int x)
{
        int i, j = 0;
        int y[10];
        for (i = 0; i < x; i++) {
                y[i % 10] = x;
                j += y[i % 10];
        }
        return (j);
}

cc -fno-asynchronous-unwind-tables -fverbose-asm -S -O sp.c

    20          .type   bar, @function
    21  bar:
    22          movl    $0, %esi        #  j
    23          movl    $0, %ecx        #  i
    24          cmpl    %edi, %esi      #  x,  j
    25          jge     .L8
    26          movl    $10, %r8d
    28  .L6:
    29          movl    %ecx, %eax      #  i
    30          cltd
    31          idivl   %r8d
    32          movslq  %edx,%rdx
    33          movl    %edi, -56(%rsp,%rdx,4)  #  x,  y
    34          addl    %edi, %esi      #  x,  j
    35          incl    %ecx    #  i
    36          cmpl    %edi, %ecx      #  x,  i
    37          jl      .L6
    38  .L8:
    39          movl    %esi, %eax      #  j
    40          ret

As you'll note, %rsp is not decremented anyhere, and and the 'y[10]'
array lives at SP - 56.

(-fno-asynchronous-unwind-tables is leave out the dwarf2 unwind tables)

> I hope to get a Tyan K8W this week and to have it sufficiently
> burned-in to boot amd64 next week.
> 
> > Plus there is another hairball to deal with.. the red zone..  The
> > 128 bytes below the stack pointer are reserved for private use of
> > leaf functions or scratch area.  This means that the signal handlers
> > need to skip over it, and anything that copies the stack has to
> > include the extra 128 bytes.
> 

Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031202062821.574D32A7EA>