#include <iostream>
int foo(int a, int b, int c, int d) {
int e;
int f;
std::cout << std::hex;
std::cout << "Address of a: " << &a << std::endl;
std::cout << "Address of b: " << &b << std::endl;
std::cout << "Address of c: " << &c << std::endl;
std::cout << "Address of d: " << &d << std::endl;
std::cout << "Address of e: " << &e << std::endl;
std::cout << "Address of f: " << &f << std::endl;
return a + b + c + d;
}
int main() {
foo(4, 2, 3, 4);
return 0;
}
输出:
gcc 4.9.2 -32bit release:
Address of a: 0x6efea0
Address of b: 0x6efea4
Address of c: 0x6efea8
Address of d: 0x6efeac
Address of e: 0x6efe8c
而就我目前的知识了解,栈是从高地址到底地址存储数据,而读取参数的顺序为从右到左,以第一次函数调用为例,入栈顺序应该是:d-c-b-a之后是按顺序将局部变量入栈,即e-f,但是比较e和a的地址可以发现二者在32位下相差14个字节,在64位下相差36个字节,感到比较奇怪,按之前看到的文章:http://blog.csdn.net/tdgx2004...,在局部变量与参数之间应该是函数地址与保护栈底(32位下8个字节),但是实际情况是14个字节,非常好奇还有6个字节装的是什么?
求教大神们。
下面是foo函数的汇编:
foo(int,int,int,int)
0x00401500 <+0>: push %ebp
0x00401501 <+1>: mov %esp,%ebp
0x00401503 <+3>: sub $0x28,%esp
0x00401506 <+6>: movl $0x479590,(%esp)
0x0040150d <+13>: mov $0x488140,%ecx
0x00401512 <+18>: call 0x451580 <_ZNSolsEPFRSt8ios_baseS0_E>
0x00401517 <+23>: sub $0x4,%esp
0x0040151a <+26>: movl $0x489000,0x4(%esp)
0x00401522 <+34>: movl $0x488140,(%esp)
0x00401529 <+41>: call 0x47b500 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc>
0x0040152e <+46>: lea 0x8(%ebp),%ecx
0x00401531 <+49>: mov %ecx,(%esp)
0x00401534 <+52>: mov %eax,%ecx
0x00401536 <+54>: call 0x4515c0 <_ZNSolsEPKv>
0x0040153b <+59>: sub $0x4,%esp
0x0040153e <+62>: movl $0x4795c0,(%esp)
0x00401545 <+69>: mov %eax,%ecx
0x00401547 <+71>: call 0x451570 <_ZNSolsEPFRSoS_E>
0x0040154c <+76>: sub $0x4,%esp
0x0040154f <+79>: movl $0x48900f,0x4(%esp)
0x00401557 <+87>: movl $0x488140,(%esp)
0x0040155e <+94>: call 0x47b500 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc>
0x00401563 <+99>: mov %eax,%edx
0x00401565 <+101>: lea 0xc(%ebp),%eax
0x00401568 <+104>: mov %eax,(%esp)
0x0040156b <+107>: mov %edx,%ecx
0x0040156d <+109>: call 0x4515c0 <_ZNSolsEPKv>
0x00401572 <+114>: sub $0x4,%esp
0x00401575 <+117>: movl $0x4795c0,(%esp)
0x0040157c <+124>: mov %eax,%ecx
0x0040157e <+126>: call 0x451570 <_ZNSolsEPFRSoS_E>
0x00401583 <+131>: sub $0x4,%esp
0x00401586 <+134>: movl $0x48901e,0x4(%esp)
0x0040158e <+142>: movl $0x488140,(%esp)
0x00401595 <+149>: call 0x47b500 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc>
0x0040159a <+154>: mov %eax,%edx
0x0040159c <+156>: lea 0x10(%ebp),%eax
0x0040159f <+159>: mov %eax,(%esp)
0x004015a2 <+162>: mov %edx,%ecx
0x004015a4 <+164>: call 0x4515c0 <_ZNSolsEPKv>
0x004015a9 <+169>: sub $0x4,%esp
0x004015ac <+172>: movl $0x4795c0,(%esp)
0x004015b3 <+179>: mov %eax,%ecx
0x004015b5 <+181>: call 0x451570 <_ZNSolsEPFRSoS_E>
0x004015ba <+186>: sub $0x4,%esp
0x004015bd <+189>: movl $0x48902d,0x4(%esp)
0x004015c5 <+197>: movl $0x488140,(%esp)
0x004015cc <+204>: call 0x47b500 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc>
0x004015d1 <+209>: mov %eax,%edx
0x004015d3 <+211>: lea 0x14(%ebp),%eax
0x004015d6 <+214>: mov %eax,(%esp)
0x004015d9 <+217>: mov %edx,%ecx
0x004015db <+219>: call 0x4515c0 <_ZNSolsEPKv>
0x004015e0 <+224>: sub $0x4,%esp
0x004015e3 <+227>: movl $0x4795c0,(%esp)
0x004015ea <+234>: mov %eax,%ecx
0x004015ec <+236>: call 0x451570 <_ZNSolsEPFRSoS_E>
0x004015f1 <+241>: sub $0x4,%esp
0x004015f4 <+244>: movl $0x48903c,0x4(%esp)
0x004015fc <+252>: movl $0x488140,(%esp)
0x00401603 <+259>: call 0x47b500 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc>
0x00401608 <+264>: mov %eax,%edx
0x0040160a <+266>: lea -0xc(%ebp),%eax
0x0040160d <+269>: mov %eax,(%esp)
0x00401610 <+272>: mov %edx,%ecx
0x00401612 <+274>: call 0x4515c0 <_ZNSolsEPKv>
0x00401617 <+279>: sub $0x4,%esp
0x0040161a <+282>: movl $0x4795c0,(%esp)
0x00401621 <+289>: mov %eax,%ecx
0x00401623 <+291>: call 0x451570 <_ZNSolsEPFRSoS_E>
0x00401628 <+296>: sub $0x4,%esp
0x0040162b <+299>: movl $0x48904b,0x4(%esp)
0x00401633 <+307>: movl $0x488140,(%esp)
0x0040163a <+314>: call 0x47b500 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc>
0x0040163f <+319>: mov %eax,%edx
0x00401641 <+321>: lea -0x10(%ebp),%eax
0x00401644 <+324>: mov %eax,(%esp)
0x00401647 <+327>: mov %edx,%ecx
0x00401649 <+329>: call 0x4515c0 <_ZNSolsEPKv>
0x0040164e <+334>: sub $0x4,%esp
0x00401651 <+337>: movl $0x4795c0,(%esp)
0x00401658 <+344>: mov %eax,%ecx
0x0040165a <+346>: call 0x451570 <_ZNSolsEPFRSoS_E>
0x0040165f <+351>: sub $0x4,%esp
0x00401662 <+354>: mov 0x8(%ebp),%edx
0x00401665 <+357>: mov 0xc(%ebp),%eax
0x00401668 <+360>: add %eax,%edx
0x0040166a <+362>: mov 0x10(%ebp),%eax
0x0040166d <+365>: add %eax,%edx
0x0040166f <+367>: mov 0x14(%ebp),%eax
0x00401672 <+370>: add %edx,%eax
=> 0x00401674 <+372>: leave
0x00401675 <+373>: ret
LZ、アセンブリ コードの一部を配置し、コンパイル時に -S を追加するだけです。
リーリーコードを実行したところ、出力は次のようになります:
e と a の差は 0x10、10 進数で 16 です。
あなたのコードを使用してアセンブリを生成したところ、foo() のパラメータがスタックにプッシュされておらず、最初にパラメータが登録されてから、レジスタ値がスタックに格納されていることがわかりました。 、つまり、あなたの状況と似ていますが、a のアドレスが d のアドレスよりも高く、これらのパラメーターのアドレスがローカル変数より小さいことがわかります。
リーリー リーリーこの問題は、プラットフォーム、採用されている呼び出し規約、およびコンパイラーに関連しています。
i386 プラットフォームでは、デフォルトの _cdecl 呼び出し規則の下で、ランタイム スタック上で、関数パラメーターと関数ローカル変数の間は、1: 戻りアドレス (呼び出し命令後の PC)、2: 呼び出し元のスタック フレーム ベース アドレス (ebp)、3:呼び出し先保存レジスタ (プラットフォームによって番号は異なります)、4: 例外を処理するためにスタックに追加される情報 (コンパイラによって実装されるものは異なる場合があり、gcc によって追加されるものがあります)