linux - Why do the 32-bit and 64-bit Compiled Versions of this Program Populate Memory in this Way? -

linux - Why do the 32-bit and 64-bit Compiled Versions of this Program Populate Memory in this Way? -

i trying improve understand how stack , heap work. have run snag when comparing 32-bit , 64-bit compiled versions of same program. in both cases used invitee fedora 15 vm (both 32 , 64), gcc compiling, gdb debugging, , same host hardware. programme in question simple , below:

c program void function(int a, int b, int c, int d){ int value; char buffer[10]; value = 1234; buffer[0] = 'a'; } int main(){ function(1, 2, 3, 4); }

in involvement of space, omitted assembly dump of program; if thinks might help them reply questions, i'd happy include it.

32-bit compiled program:

parameters 4 (0xbffff3e4), 3 (0xbffff3e0), 2 (0xbffff3dc) , 1 (0xbffff3d8) pushed onto stack first. next location of instruction following phone call function()--or homecoming address--is placed on stack (0x080483d1). next value of base of operations pointer previous stack (0xbffff3e8) pushed on stack.

(gdb) x/16xw $esp 0xbffff3c0: 0x00000000 0x410759c3 0x4105d237 0x00000000 0xbffff3d0: 0xbffff3e8 0x080483d1 0x00000001 0x00000002//pointers 0xbffff3e0: 0x00000003 0x00000004 0x00000000 0x4105d413//followed params 0xbffff3f0: 0x00000001 0xbffff484 0xbffff48c 0x41040fc4 64-bit compiled program:

however; here values 4, 3, 2, , 1 seen. can see, no matter how far downwards stack homecoming address (0x4004ae) , previous stack frame's base of operations pointer (0x7fffffffe210).

(gdb) x/16xg $rsp 0x7fffffffe200: 0x00007fffffffe210 0x00000000004004ae //pointers 0x7fffffffe210: 0x0000000000000000 0x00000036d042139d 0x7fffffffe220: 0x0000000000000000 0x00007fffffffe2f8 0x7fffffffe230: 0x0000000100000000 0x0000000000400491 0x7fffffffe240: 0x0000000000000000 0x7ade47f577d82f75 0x7fffffffe250: 0x0000000000400390 0x00007fffffffe2f0 0x7fffffffe260: 0x0000000000000000 0x0000000000000000 0x7fffffffe270: 0x8521b80ab3982f75 0x7ab3e77151682f75 64-bit compiled programme print statement:

now, after adding simple print statement:

printf("%d, %c\n", flag, buffer[0]);

in function(), can see wayward parameters (see below, 0x7fffffffe1e0-0x7fffffffe1ec). can see base of operations pointer previous stack frame, 0x7fffffffe210 (in 0x7fffffffe200) , homecoming address 0x400520 (in 0x7fffffffe208). believe changed due new print statement. why 4, 3, 2, , 1 not visible without print statement in case? 64-bit implementation of gcc compiler smart plenty not 'waste' memory parameters , local variables never used?

(gdb) x/16xg $rsp 0x7fffffffe1e0: 0x0000000300000004 0x0000000100000002 //parameters 0x7fffffffe1f0: 0x0000000000000000 0x00000000004003e0 0x7fffffffe200: 0x00007fffffffe210 0x0000000000400520 //pointers 0x7fffffffe210: 0x0000000000000000 0x00000036d042139d 0x7fffffffe220: 0x0000000000000000 0x00007fffffffe2f8 0x7fffffffe230: 0x0000000100000000 0x0000000000400503 0x7fffffffe240: 0x0000000000000000 0xd3c0c92559feaed9 0x7fffffffe250: 0x00000000004003e0 0x00007fffffffe2f0

finally, why 32 bit os place parameters 4, 3, 2, , 1 higher in stack mentioned pointers. , why 64 bit os instead place parameters lower in stack said pointers? under impression passed parameters placed on stack first (and hence, in larger-value memory address since stack grows toward smaller addresses). saved base of operations pointer , homecoming address followed (so base of operations pointer reset previous value , calling function returned to). behavior observing in 32-bit compiled code, not 64-bit version. misunderstanding? appreciate insight matter , apologize if questions unclear. please allow me know way can more concise (or if factually wrong @ point).

thank in advance.

the 64-bit abi used linux differs considerably 32-bit abi: in 64-bit world, arguments passed in registers, rather on stack.

before adding printf(), you're not finding arguments on stack because first (up to) 6 integer or pointer arguments passed in registers (in order %rdi, %rsi, %rdx, %rcx, %r8, %r9).

after adding printf(), saved on stack in process of register contents beingness shuffled around printf() phone call - take @ assembly; it's obvious 1 time know abi looks like.

linux compiler-construction stack x86 x86-64