stack allocation and gcc

stack allocation and gcc

[Ihar 'Philips' Filipau]

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:

--- objdump/ix86 -------------------
00000000 <a>:
    0:   55                      push   %ebp
    1:   89 e5                   mov    %esp,%ebp
    3:   83 ec 68                sub    $0x68,%esp
    6:   83 7d 08 05             cmpl   $0x5,0x8(%ebp)
    a:   7e 1c                   jle    28 <a+0x28>
    c:   83 ec 08                sub    $0x8,%esp
    f:   8d 45 b8                lea    0xffffffb8(%ebp),%eax
   12:   50                      push   %eax
   13:   8d 45 d8                lea    0xffffffd8(%ebp),%eax
   16:   50                      push   %eax
   17:   e8 fc ff ff ff          call   18 <a+0x18>
                         18: R_386_PC32  printf
   1c:   83 c4 10                add    $0x10,%esp
   1f:   b8 01 00 00 00          mov    $0x1,%eax
   24:   c9                      leave
   25:   c3                      ret
   26:   89 f6                   mov    %esi,%esi
   28:   83 ec 08                sub    $0x8,%esp
   2b:   8d 45 98                lea    0xffffff98(%ebp),%eax
   2e:   eb e2                   jmp    12 <a+0x12>
------------------------------------

--- objdump/ppc82xx ----------------
00000000 <a>:
    0:   94 21 ff 90     stwu    r1,-112(r1)
    4:   7c 08 02 a6     mflr    r0
    8:   90 01 00 74     stw     r0,116(r1)
    c:   2c 03 00 05     cmpwi   r3,5
   10:   40 81 00 18     ble     28 <a+0x28>
   14:   38 61 00 08     addi    r3,r1,8
   18:   38 81 00 28     addi    r4,r1,40
   1c:   4c c6 31 82     crclr   4*cr1+eq
   20:   48 00 00 01     bl      20 <a+0x20>
                         20: R_PPC_REL24 printf
   24:   48 00 00 14     b       38 <a+0x38>
   28:   38 61 00 08     addi    r3,r1,8
   2c:   38 81 00 48     addi    r4,r1,72
   30:   4c c6 31 82     crclr   4*cr1+eq
   34:   48 00 00 01     bl      34 <a+0x34>
                         34: R_PPC_REL24 printf
   38:   38 60 00 01     li      r3,1
   3c:   80 01 00 74     lwz     r0,116(r1)
   40:   7c 08 03 a6     mtlr    r0
   44:   38 21 00 70     addi    r1,r1,112
   48:   4e 80 00 20     blr
------------------------------------

-- 
Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--                                                           _ _ _
  "... and for $64000 question, could you get yourself       |_|*|_|
    vaguely familiar with the notion of on-topic posting?"   |_|_|*|
                                 -- Al Viro @ LKML           |*|*|*|

Re: stack allocation and gcc

[Jaco Kroon]

[-- Attachment #1: Type: text/plain, Size: 3220 bytes --]

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3174 bytes --]

Re: stack allocation and gcc

[Bart Hartgers]

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

Re: stack allocation and gcc

[Richard B. Johnson]

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.

Re: stack allocation and gcc

[Ihar 'Philips' Filipau]

Duncan Sands wrote:
> It sounds like "stack alignment", which makes sure that
> every stack frame is aligned on a multiple of (for example)
> 32 bytes.  Check out -falign-functions.
> 

   -falign-function=1 -> No difference.

   And as 'info gcc' states it affects alignment of function entry points.

   '-mpreffered-stack-boundary=2' sort'a kind'a helped - I have reduced 
stack size of 108 bytes to 106 :-)

-- 
Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--                                                           _ _ _
  "... and for $64000 question, could you get yourself       |_|*|_|
    vaguely familiar with the notion of on-topic posting?"   |_|_|*|
                                 -- Al Viro @ LKML           |*|*|*|

Re: stack allocation and gcc

[Ihar 'Philips' Filipau]

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
> 

   0x68 != 68.

   [ All known to me assemblers on ix86 use hexadecimal number by 
default. I was sort of surprised to find out that ppc gas uses decimal 
numbers only. ]

   0x68 == 104 == 32*3 + 4 + 4.

   As I have said, keep adding to function 'do { char buf[32]; 
printf(buf); } while(0)' increse this number. As in my logic it is 
supposed to be unchanged - all renundant buffers do have same size - 32 
bytes.

-- 
Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--                                                           _ _ _
  "... and for $64000 question, could you get yourself       |_|*|_|
    vaguely familiar with the notion of on-topic posting?"   |_|_|*|
                                 -- Al Viro @ LKML           |*|*|*|

Re: stack allocation and gcc

[Ihar 'Philips' Filipau]

Richard B. Johnson wrote:
> 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

    It was my first thought actually - when I have started typeing in 
e-mail.

    When I have reached half e-mail - I have understood that this is 
simple performance consideration - stack space is allocated once.

    I have tryed to convert my e-mail to another issue - but seems I did 
it not good enough :-)

    But then I realized that my thinking was wrong - I'm using variables 
in different never overlapping contextes. But space allocated for 
everyone. "if (..) { int i; }; if (...) { int i; }" will result not in 
sizeof(int) stack space allocated - but in sizeof(int)*2.

    It seems that gcc check size required by all top level contextes in 
function - it checks for "if { int a[16] } else { int a[16] }" - space 
allocated correctly.
    But 'if () { int a[16]; }; if () { int a[16] };' seems to break 
something, and sum of the sizes for both if()'s spaces finishes 
allocated on stack. And this was the case with macro in my module.

    I doubt I can write competent report/query to gcc mail list - 
probably it is worth to ask there.

-- 
Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--                                                           _ _ _
  "... and for $64000 question, could you get yourself       |_|*|_|
    vaguely familiar with the notion of on-topic posting?"   |_|_|*|
                                 -- Al Viro @ LKML           |*|*|*|

IBM Thinkpad with docking station

[Frank Fiene]

Hi, i've problem with my Thinkpad A31p, USB and docking station.

Without the docking station, USB is working fine, if i plugin my 
notebook, following errors occur (i remember, that before upgrading to 
2.6.3 only one port could be used and with windoze both ports are ok):

hub 1-0:1.0: usb_probe_interface
hub 1-0:1.0: usb_probe_interface - got id
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
hub 1-0:1.0: standalone hub
hub 1-0:1.0: unknown reserved power switching mode
hub 1-0:1.0: individual port over-current protection
hub 1-0:1.0: Port indicators are not supported
hub 1-0:1.0: power on to power good time: 2ms
hub 1-0:1.0: hub controller current requirement: 0mA
hub 1-0:1.0: local power source is good
hub 1-0:1.0: no over-current condition exists
hub 1-0:1.0: enabling power on all ports
hub 1-0:1.0: port 1, status 101, change 1, 12 Mb/s
uhci_hcd 0000:00:1d.1: root hub device address 1
hub 2-0:1.0: usb_probe_interface
hub 2-0:1.0: usb_probe_interface - got id
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
hub 2-0:1.0: standalone hub
hub 2-0:1.0: unknown reserved power switching mode
hub 2-0:1.0: individual port over-current protection
hub 2-0:1.0: Port indicators are not supported
hub 2-0:1.0: power on to power good time: 2ms
hub 2-0:1.0: hub controller current requirement: 0mA
hub 2-0:1.0: local power source is good
hub 2-0:1.0: no over-current condition exists
hub 2-0:1.0: enabling power on all ports
hub 1-0:1.0: debounce: port 1: delay 100ms stable 4 status 0x101
uhci_hcd 0000:00:1d.2: root hub device address 1
hub 1-0:1.0: port 1 not reset yet, waiting 50ms
hub 1-0:1.0: port 1 not reset yet, waiting 200ms
hub 3-0:1.0: usb_probe_interface
hub 3-0:1.0: usb_probe_interface - got id
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
hub 3-0:1.0: standalone hub
hub 3-0:1.0: unknown reserved power switching mode
hub 3-0:1.0: individual port over-current protection
hub 3-0:1.0: Port indicators are not supported
hub 3-0:1.0: power on to power good time: 2ms
hub 3-0:1.0: hub controller current requirement: 0mA
hub 3-0:1.0: local power source is good
hub 3-0:1.0: no over-current condition exists
hub 3-0:1.0: enabling power on all ports
hub 1-0:1.0: port 1 not reset yet, waiting 200ms
hub 1-0:1.0: port 1 not reset yet, waiting 200ms
hub 1-0:1.0: port 1 not enabled, trying reset again...
hub 1-0:1.0: port 1 not reset yet, waiting 200ms
hub 1-0:1.0: port 1 not reset yet, waiting 200ms
hub 1-0:1.0: port 1 not reset yet, waiting 200ms
hub 1-0:1.0: port 1 not enabled, trying reset again...
hub 1-0:1.0: port 1 not reset yet, waiting 200ms
hub 1-0:1.0: port 1 not reset yet, waiting 200ms
hub 1-0:1.0: port 1 not reset yet, waiting 200ms
hub 1-0:1.0: port 1 not enabled, trying reset again...
hub 1-0:1.0: port 1 not reset yet, waiting 200ms
hub 1-0:1.0: port 1 not reset yet, waiting 200ms
hub 1-0:1.0: port 1 not reset yet, waiting 200ms
hub 1-0:1.0: port 1 not enabled, trying reset again...
hub 1-0:1.0: port 1 not reset yet, waiting 200ms
hub 1-0:1.0: port 1 not reset yet, waiting 200ms
hub 1-0:1.0: port 1 not reset yet, waiting 200ms
hub 1-0:1.0: port 1 not enabled, trying reset again...
hub 1-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?

-- 
uniorg Solutions GmbH - Märkische Strasse 237 - 44141 Dortmund
ffiene@veka.com - Tel:0231-9497-262
--
Ein Unternehmen der uniorg-Gruppe