Re: stack allocation and gcc

Richard B. Johnson
2004-03-10T13:21:02Z

The caller expects that the space for the second set of local
variables in the second program unit is not allocated until the
program unit is entered.

I don't know why he would expect this behavior. Certainly
the space for the local variables in the first program unit
is allocated at compile-time. I don't know why he would
expect that the variables in the second or subsequent
program units would be handled any differently.

I have seen this misconception before. If the caller needs
to dynamically allocate local space, dependent upon condition,
he should do something like this:

foo(....)
{
size_t len;
char buf0[SOME_SIZE];
len = strlen(buf0) + 1;
{
buf1[len]; // Second program unit buffer

}

This ends up being coded as a simple subtraction from the stack-
pointer to allocate the new space in the new program unit.

In general, the allocation for all local variables is done
at compile-time and the allocation for all globals is done
at link-time. In this context, 'allocation' means calculation
of offsets and displacements, not the allocation and relocation
that occurs when a program is executed.

On Wed, 10 Mar 2004, Jaco Kroon wrote:

> Hi Ihar,
>
> In your code you have 3 buffers, one in the mani branch of 32 bytes and
> one of 32 bytes in each of the sub branches. This adds up to a total of
> 64 bytes since as you say, the two buffers named buf2[32] can be
> shared. Thus it is 32 bytes for buf and 32 bytes for the shared
> buffer. Now if you look at the function startup code:
>
> 0: 55 push %ebp
> 1: 89 e5 mov %esp,%ebp
> 3: 83 ec 68 sub $0x68,%esp
>
> THe push saves the frame pointer (ebp). The mov sets up the new stack
> frame and the sub allocates space of 68 bytes on the stack, 4 bytes more
> than the expected 64, this is probably for temporary storage required
> somewhere in the function. As such, gcc does not allocate 32 bytes too
> many (at least not on i386, but probably not on other architectures either).
>
> Jaco
>
> Ihar 'Philips' Filipau wrote:
>
> > Hello All!
> >
> > [ please cc: me ]
> >
> > I have observed funny behaviour of both gcc 2.95/322 on ppc32 and
> > i686 platforms.
> >
> > Have written this routine and compiled it with 'gcc -O2':
> >
> > int a(int v)
> > {
> > char buf[32];
> >
> > if (v > 5) {
> > char buf2[32];
> > printf( buf, buf2 );
> > } else {
> > char buf2[32];
> > printf( buf, buf2 );
> > }
> > return 1;
> > }
> >
> > I expected that stack on every branch of 'if(v>5)' will be
> > allocated later - but seems that gcc allocate stack space once and in
> > this case it will 'overallocate' 32 bytes - 'char buf2' will be
> > allocated twice for every branch. On i686 gcc allocates 108 bytes, on
> > ppc32 it allocates 116 bytes. (additional space seems to be induced by
> > printf() call)
> > Adding to this routine something like 'do { char a[32]; }
> > while(0);' several times shows that stack buffers are not reused - and
> > allocated for every this kind of context separately.
> >
> > As to my understanding - since this buffers do live in different
> > mutually exclusive contextes - they can be reused. But this seems to
> > be not case. Waste of precious kernel stack space - and waste of d-cache.
> >
> > I have read 'info gcc' - but found nothing relevant to this.
> > I've checked ppc abi - but found no limitations to reuse of stack
> > space.
> >
> > Is it expected behaviour of compiler? gcc feature?
> >
> > [ I have created macro which opens into inline function call which
> > utilizes va_list - on ppc32 va_list adds at least 32 bytes to stack
> > use. Seems to be bad idea for kernel-space, since every use if macro
> > adds to stack use (10 macro calls == 320 bytes). Easy to rewrite to
> > not to use va_list - but have I *NO* stack allocation check script in
> > place - this stuff could easily get into production release. Not nice. ]
> >
> > disassembling outputs:
> >
> ===========================================
> This message and attachments are subject to a disclaimer. Please refer to www.it.up.ac.za/documentation/governance/disclaimer/ for full details.
> Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule onderhewig. Volledige besonderhede is by www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar.
> ===========================================
>
>

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.