This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Purpose of GCC Stack Padding?
- From: "Andrew Tomazos" <andrew at tomazos dot com>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 16 Dec 2008 23:23:27 +0100
- Subject: Purpose of GCC Stack Padding?
I've been studying the x86 compiled form of the following function:
void function()
{
char buffer[X];
}
where X = 0, 1, 2 .. 100
Naively, I would expect to see:
pushl %ebp
movl %esp, %ebp
subl $X, %esp
leave
ret
Instead, the stack appears to be padded:
For a buffer size of 0 the stack size is 0
For a buffer size of 1 to 7 the stack size is 16
For a buffer size of 8 to 12 the stack size is 24
For a buffer size of 13 to 28 the stack size is 40
For a buffer size of 29 to 44 the stack size is 56
For a buffer size of 45 to 60 the stack size is 72
For a buffer size of 61 to 76 the stack size is 88
For a buffer size of 77 to 92 the stack size is 104
For a buffer size of 93 to 100 the stack size is 120
When X >= 8 gcc adds a stack corruption check (__stack_chk_fail),
which accounts for an extra 4 bytes of stack space in these cases.
This does not explain the rest of the padding. Can anyone explain the
purpose of the rest of the padding?
Thanks,
Andrew.
PS There is a related thread on comp.lang.asm.x86. It contains the
script I used to compile the function and the full output:
http://groups.google.com/group/comp.lang.asm.x86/browse_thread/thread/2c8c5a2c6050179b/
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
--
Andrew Tomazos <andrew@tomazos.com> <http://www.tomazos.com>