关于CSAPP lab3中压栈问题引发的思考
浏览数：39 /
时间：2015年06月11日
之前有个问题也没特别注意，今天回来看邮件发现有同学和我讨论关于函数调用压栈的问题。
废话少说，直接上对比测试图:
图一：CSAPP lab3的getbuf反汇编结果截图
图二: 我测试，节选了部分的getbuf实现，然后很简单的去测试getbuf的反汇编结果，反汇编结果如下图
我究竟是怎么测试的：
unsigned long long getbuf()
{
char buf[36];
volatile char* variable_length;
int i;
unsigned long long val;
return val % 40;
}
int main()
{
getbuf();
return 0;
}个人还是觉得测试代码没问题的。主要就是观察buf数组到底怎么被压栈的。保留其他的局部变量就可以了，理论上不会影响esp自减开辟新栈的大小。
但是但是。。。
Q1:
童鞋们能很明显的看出这里前后两个反汇编的结果不同。
前者开辟了0x30的大小的stack frame
后者开辟了0x40的大小的stack frame。
Q2:
利用CSAPP的可执行程序，gdb调试，然后查看反汇编程序。
观察寄存器rbp和buf的地址。
也就是说 buf数组距离栈基地址（rbp寄存器指向处），相差了0x30的大小。
而这段区域内应该只存在buf数组元素，无其他变量或者寄存器被压栈。于是我就怀疑这个buf数组（本来只有36byte）被对齐到了48byte(0x30), 但是这又无法解释， 因为如果按照64位操作系统的话，8byte对齐，只要对齐到
0x28就可以了，不用0x30. 这里相差的8byte就是个疑问。
有高手路过，恳请指导。。。
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
