Re: stack allocation and gcc

From: Jaco Kroon (jkroon_at_cs.up.ac.za)
Date: 03/10/04

  • Next message: Rik van Riel: "Re: [lockup] Re: objrmap-core-1 (rmap removal for file mappings to avoid 4:4 in <=16G machines)" 
    Date:	Wed, 10 Mar 2004 14:55:40 +0200
To: Ihar 'Philips' Filipau <filia@softhome.net>

    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.
    ===========================================

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Rik van Riel: "Re: [lockup] Re: objrmap-core-1 (rmap removal for file mappings to avoid 4:4 in <=16G machines)"

    Relevant Pages

    • Re: "Heap" (was Re: static, global variable memory allocation)
      ... common to refer to the area used to allocate automatic objects ... Can a perverse but conforming implementation use the "heap" for ... used a linked list of save areas instead of a stack. ... CPU-specific region of memory that grows linearly in one direction, ...
      (comp.lang.c)
    • Re: style question,itoa
      ... able to allocate buffers in some convenient location the callee ... dynamically allocate a block of memory and computing this size to use ... call might require allocating a page for the stack. ... " Checking every single malloc in a bigger application for possible ...
      (comp.unix.programmer)
    • Re: run-time vs compile-time
      ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
      (alt.comp.lang.learn.c-cpp)
    • Re: run-time vs compile-time
      ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
      (comp.lang.cpp)
    • [PATCH 6 of 18] ipath - chip initialisation code
      ... * buffers per port, etc.) Zero means use chip value. ... * Allocate the eager TID buffers and program them into infinipath. ... * ensure no receive or transmit (explictly, in case reset ...
      (Linux-Kernel)
    Loading