当前位置 : 主页 > 网络推广 > seo >

从/ proc / pid / stat中检索当前堆栈指针

来源:互联网 收集:自由互联 发布时间:2021-06-16
我正在使用gdb执行一个基本的C程序.我在main()的开头有一个断点.运行代码后,gdb按预期在main()处中断. 现在,如果我检查堆栈指针寄存器(rsp),我看到了 0x7fffffffe170: 0x00000000. 当我使用cat /
我正在使用gdb执行一个基本的C程序.我在main()的开头有一个断点.运行代码后,gdb按预期在main()处中断.
现在,如果我检查堆栈指针寄存器(rsp),我看到了

0x7fffffffe170: 0x00000000.

当我使用cat / proc / 17232 / stat |检索相同的信息时cut -d“”-f29 / proc(其中17232是这个过程的pid),我看到:

140737488347112 (which in hex is: 0x7fffffffdfe8).

为什么我们看到来自gdb的当前堆栈指针的不同值.而且,为什么gdb将rsp的内容显示为NULL(0x00000000)?

谢谢.

从/ proc打印rsp寄存器(在64b cpus上)

(gdb) info register rsp
rsp            0x7fffffffe480   0x7fffffffe480

与/ proc相比,确实给出了不同的值

me@linux:~$cat /proc/22219/stat | cut -d" " -f29 | perl -e 'print(sprintf("%x\n",<>));'
7fffffffe338

因为gdb必须在主函数开始时强制程序中的interruption才能接管执行,并且最小的数据集(返回地址,一些寄存器备份)被保存到堆栈中.然后,gdb使用自己的堆栈不溢出程序,并在请求查看寄存器或处理堆栈数据时进行必要的调整操作 – 并且不显示内部gdb烹饪.但/ proc显示实际数据,不变.

来自/ proc的“真实”rsp实际上略小于gdb,因为在x86 cpus上,堆栈向下增长.

至于null值,在我的测试期间没有发生

(gdb) x 0x7fffffffe480
0x7fffffffe480: 0xffffe578
网友评论