[ot] allocation

[DevarajA]

Hi, I can't uderstand something about the local variables allocation on
the stack. Maybe I'm OT, I know... Here's the function, compiled on a
i386 computer with linux

/******************/
void funz(char *txt)
{
char buf[12];
strcpy(buf,txt); /*done intentionally*/
}
/*********************/

$gcc bof.c --static
$gdb a.out
(gdb)disassemble funz
Dump of assembler code for function funz:
0x08048214 <funz+0>: push %ebp <<ok, saves frame pointer
0x08048215 <funz+1>: mov %esp,%ebp <<ok, updates frame pointer
0x08048217 <funz+3>: sub $0x28,%esp <<???

This instruction reserves 40 bytes of the stack for local variables,
while I only have 12 bytes. What are the remaining 28 bytes used for?
Maybe you can tell from the following asm code, because I can't

0x0804821a <funz+6>: mov 0x8(%ebp),%eax
0x0804821d <funz+9>: mov %eax,0x4(%esp)
second argument on the second position of the stack
0x08048221 <funz+13>: lea 0xffffffe8(%ebp),%eax
what does this do? and what's in the middle of the stack?
0x08048224 <funz+16>: mov %eax,(%esp)
0x08048227 <funz+19>: call 0x804de00 <strcpy>
moves that thing on top of the stack and calls strcpy

From this code it looks like if strcpy wanted its arguments on the top
of the stack (nothing strange), but they one of them is initially in the
middle of that oversize stack. I can't understend why. Wouldn't be
simplier to push on the stack a copy of 0x8(%ebp) and 0xfffffffc(%ebp)?
Thank you in advance.

0x0804822c <funz+24>: leave
0x0804822d <funz+25>: ret

 

[Maw]

try to compile with gcc's -Os flag

 

[DevarajA]

Maw ha scritto:

try to compile with gcc's -Os flag

It just uses edx instead of eax when swapping stack entries.

 

[Alipha]

Hi, I can't uderstand something about the local variables allocation on
the stack. Maybe I'm OT, I know... Here's the function, compiled on a
i386 computer with linux

/******************/
void funz(char *txt)
{
char buf[12];
strcpy(buf,txt); /*done intentionally*/
}
/*********************/

$gcc bof.c --static
$gdb a.out
(gdb)disassemble funz
Dump of assembler code for function funz:
0x08048214 <funz+0>: push %ebp <<ok, saves frame pointer
0x08048215 <funz+1>: mov %esp,%ebp <<ok, updates frame pointer
0x08048217 <funz+3>: sub $0x28,%esp <<???

This instruction reserves 40 bytes of the stack for local variables,
while I only have 12 bytes. What are the remaining 28 bytes used for?
Maybe you can tell from the following asm code, because I can't

i can only assume it has to do with alignment. however, i can't imagine
aligning to the 48-byte boundary (40 local bytes + ret addr + stack
pointer) would be any more useful than the nearest 8-byte or 16-byte
boundary.

0x0804821a <funz+6>: mov 0x8(%ebp),%eax
0x0804821d <funz+9>: mov %eax,0x4(%esp)
second argument on the second position of the stack
0x08048221 <funz+13>: lea 0xffffffe8(%ebp),%eax
what does this do? and what's in the middle of the stack?
0x08048224 <funz+16>: mov %eax,(%esp)
0x08048227 <funz+19>: call 0x804de00 <strcpy>
moves that thing on top of the stack and calls strcpy

From this code it looks like if strcpy wanted its arguments on the top
of the stack (nothing strange), but they one of them is initially in the
middle of that oversize stack. I can't understend why. Wouldn't be
simplier to push on the stack a copy of 0x8(%ebp) and 0xfffffffc(%ebp)?
Thank you in advance.

note that 0xfffffffc(%ebp) would be the end of the array.
0xffffffe8(%ebp) is the beginning of the array.

 

[Artie Gold]

Hi, I can't uderstand something about the local variables allocation on
the stack. Maybe I'm OT, I know... Here's the function, compiled on a
i386 computer with linux

/******************/
void funz(char *txt)
{
char buf[12];
strcpy(buf,txt); /*done intentionally*/
}
/*********************/

$gcc bof.c --static
$gdb a.out
(gdb)disassemble funz
Dump of assembler code for function funz:
0x08048214 <funz+0>: push %ebp <<ok, saves frame pointer
0x08048215 <funz+1>: mov %esp,%ebp <<ok, updates frame pointer
0x08048217 <funz+3>: sub $0x28,%esp <<???

This instruction reserves 40 bytes of the stack for local variables,
while I only have 12 bytes. What are the remaining 28 bytes used for?
Maybe you can tell from the following asm code, because I can't

0x0804821a <funz+6>: mov 0x8(%ebp),%eax
0x0804821d <funz+9>: mov %eax,0x4(%esp)
second argument on the second position of the stack
0x08048221 <funz+13>: lea 0xffffffe8(%ebp),%eax
what does this do? and what's in the middle of the stack?
0x08048224 <funz+16>: mov %eax,(%esp)
0x08048227 <funz+19>: call 0x804de00 <strcpy>
moves that thing on top of the stack and calls strcpy

From this code it looks like if strcpy wanted its arguments on the top
of the stack (nothing strange), but they one of them is initially in the
middle of that oversize stack. I can't understend why. Wouldn't be
simplier to push on the stack a copy of 0x8(%ebp) and 0xfffffffc(%ebp)?
Thank you in advance.

0x0804822c <funz+24>: leave
0x0804822d <funz+25>: ret

Please take your question to -- but first search the
archives there, as this issue (or ones like it) have been discussed
recently and often.

Cheers,
--ag

 

[Keith Thompson]

Hi, I can't uderstand something about the local variables allocation
on the stack. Maybe I'm OT, I know... Here's the function, compiled on
a i386 computer with linux

/******************/
void funz(char *txt)
{
char buf[12];
strcpy(buf,txt); /*done intentionally*/
}
/*********************/

$gcc bof.c --static
$gdb a.out
(gdb)disassemble funz
Dump of assembler code for function funz:
0x08048214 <funz+0>: push %ebp <<ok, saves frame pointer
0x08048215 <funz+1>: mov %esp,%ebp <<ok, updates frame pointer
0x08048217 <funz+3>: sub $0x28,%esp <<???

This instruction reserves 40 bytes of the stack for local variables,
while I only have 12 bytes. What are the remaining 28 bytes used for?

[snip]

Yes, this is off-topic.

A compiler may allocate additional stack space (assuming the system
has a "stack") for any purpose it likes. I can think of a number of
things the additional space might be used for, but I'm not going to
speculate. Try asking in a newsgroup for the compiler you're using;
in this case, there's a "gnu.gcc.*" hierarchy.

 

[Chris Torek]

Hi, I can't uderstand something about the local variables allocation on
the stack. Maybe I'm OT ...

Your question *is* technically off-topic, but we might turn it into
an on-topic one by re-imagining the code as C code. Now, you had,
in effect:

void f(char *arg) {
char buf[SOME_SIZE];
char *stackargs[2];
char **sp = &stackargs[2];

*--sp = arg;
*--sp = &buf[0];
otherfunc(sp);
}

The compiler has apparently compiled, instead, the following code:

void f(char *arg) {
char buf[SOMESIZE];
char *stackargs[2];

stackargs[1] = arg;
stackargs[0] = &buf[0];
otherfunc(&stackargs[0]);
}

and thus eliminated the "*--sp" bits, by writing directly to the
array elements to which "sp" would have pointed each time.

Is this change that the compiler made detectable by otherfunc()?
If so, how? If not, does eliminating the "--sp" part perhaps
produce faster or smaller machine code? Does the C standard
forbid replacing slower code with faster, equivalent-effect code?

 

[Barry Schwarz]

Hi, I can't uderstand something about the local variables allocation on
the stack. Maybe I'm OT ...

Your question *is* technically off-topic, but we might turn it into
an on-topic one by re-imagining the code as C code. Now, you had,
in effect:

void f(char *arg) {
char buf[SOME_SIZE];
char *stackargs[2];
char **sp = &stackargs[2];

*--sp = arg;
*--sp = &buf[0];
otherfunc(sp);
}

The compiler has apparently compiled, instead, the following code:

void f(char *arg) {
char buf[SOMESIZE];
char *stackargs[2];

stackargs[1] = arg;
stackargs[0] = &buf[0];
otherfunc(&stackargs[0]);
}

and thus eliminated the "*--sp" bits, by writing directly to the
array elements to which "sp" would have pointed each time.

Is this change that the compiler made detectable by otherfunc()?

sp is not in scope while otherfunc executes. Only its value is
passed. otherfunc has no idea where the value came from. I don't see
how you could code otherfunc to detect the difference.

If so, how? If not, does eliminating the "--sp" part perhaps
produce faster or smaller machine code? Does the C standard
forbid replacing slower code with faster, equivalent-effect code?

<<Remove the del for email>>