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 |*|*|*|
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 http://www.it.up.ac.za/documentation/governance/disclaimer/ for full details.
Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule onderhewig. Volledige besonderhede is by http://www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar.
===========================================
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 http://www.it.up.ac.za/documentation/governance/disclaimer/ for full
> details. Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule
> onderhewig. Volledige besonderhede is by
> http://www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar.
> ===========================================
>
--
Bart Hartgers - TUE Eindhoven
http://plasimo.phys.tue.nl/bart/contact.html
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 http://www.it.up.ac.za/documentation/governance/disclaimer/ for full details.
> Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule onderhewig. Volledige besonderhede is by http://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.
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 |*|*|*|
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 |*|*|*|
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 |*|*|*|
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
[email protected] - Tel:0231-9497-262
--
Ein Unternehmen der uniorg-Gruppe