码迷,mamicode.com
首页 > 移动开发 > 详细

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

时间:2015-05-29 23:12:20      阅读:239      评论:0      收藏:0      [点我收藏+]

标签:


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



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

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





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






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

标签:

原文地址:http://blog.csdn.net/cinmyheart/article/details/46240925

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!