Varargs issues
Peter Wemm
peter at wemm.org
Mon Dec 1 22:28:22 PST 2003
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 at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
More information about the freebsd-amd64
mailing list