关于CSAPP lab3中压栈问题引发的思考

之前有个问题也没特别注意，今天回来看邮件发现有同学和我讨论关于函数调用压栈的问题。

废话少说，直接上对比测试图:

图一：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就是个疑问。

有高手路过，恳请指导。。。