lkml.org 
[lkml]   [2004]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: stack allocation and gcc

    0x68 (hex) == 104 (dec)

    Regards,
    Bart


    On 10 Mar, 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.
    > ===========================================
    >

    --
    Bart Hartgers - TUE Eindhoven
    http://plasimo.phys.tue.nl/bart/contact.html
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 14:01    [W:0.036 / U:58.892 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site