为什么GCC8/9/10和GCC-7在计算堆栈偏移量时表现不同？

html5 • • 问答 • 216 阅读

我正在将代码移植到现代编译器，不幸的是，当从 Rust 调用 FFI 函数到 C++ 时遇到了一个微妙的分段错误。

堆栈跟踪显示，在过渡到 C++ 之后，Rust 提供的第一个参数神奇地消失了，这会误导 C++ 使用错误的参数。

代码有点私密，所以我不能在这里发布，但程序集显示了一些有趣的东西：

在 GCC-7（代码运行没有问题）中，汇编的前几行如下所示：

   0x0000000000001119 <+0>:     push   rbp
   0x000000000000111a <+1>:     mov    rbp,rsp
   0x000000000000111d <+4>:     push   r13
   0x000000000000111f <+6>:     push   r12
   0x0000000000001121 <+8>:     push   rbx
   0x0000000000001122 <+9>:     sub    rsp,0x128
   0x0000000000001129 <+16>:    mov    QWORD PTR [rbp-0x118],rdi
   0x0000000000001130 <+23>:    mov    rax,rsi
   0x0000000000001133 <+26>:    mov    rsi,rdx
   0x0000000000001136 <+29>:    mov    rdx,rsi
   0x0000000000001139 <+32>:    mov    QWORD PTR [rbp-0x130],rax
   0x0000000000001140 <+39>:    mov    QWORD PTR [rbp-0x128],rdx
   0x0000000000001147 <+46>:    mov    QWORD PTR [rbp-0x120],rcx
   0x000000000000114e <+53>:    mov    QWORD PTR [rbp-0x140],r8
   0x0000000000001155 <+60>:    mov    QWORD PTR [rbp-0x138],r9
   0x000000000000115c <+67>:    lea    rax,[rbp-0x110]
   0x0000000000001163 <+74>:    mov    rdi,rax
   0x0000000000001166 <+77>:    call   0x116b
   0x000000000000116b <+82>:    mov    rax,QWORD PTR [rbp-0x128]
   0x0000000000001172 <+89>:    mov    edx,eax
   0x0000000000001174 <+91>:    mov    rcx,QWORD PTR [rbp-0x130]
   0x000000000000117b <+98>:    lea    rax,[rbp-0x110]
   0x0000000000001182 <+105>:   mov    rsi,rcx
   0x0000000000001185 <+108>:   mov    rdi,rax
   0x0000000000001188 <+111>:   call   0x118d

   0x0000000000001119 <+0>:     push 
   0x0000000000001125 <+0>:     push   rbp
   0x0000000000001126 <+1>:     mov    rbp,rsp
   0x0000000000001129 <+4>:     push   r12
   0x000000000000112b <+6>:     push   rbx
   0x000000000000112c <+7>:     sub    rsp,0x120
   0x0000000000001133 <+14>:    mov    QWORD PTR [rbp-0x108],rdi
   0x000000000000113a <+21>:    mov    QWORD PTR [rbp-0x110],rsi
   0x0000000000001141 <+28>:    mov    QWORD PTR [rbp-0x120],rdx
   0x0000000000001148 <+35>:    mov    QWORD PTR [rbp-0x118],rcx
   0x000000000000114f <+42>:    mov    QWORD PTR [rbp-0x128],r8
   0x0000000000001156 <+49>:    mov    QWORD PTR [rbp-0x130],r9
   0x000000000000115d <+56>:    lea    rax,[rbp-0x100]
   0x0000000000001164 <+63>:    mov    rdi,rax
   0x0000000000001167 <+66>:    call   0x116c
   0x000000000000116c <+71>:    mov    rax,QWORD PTR [rbp-0x118]
   0x0000000000001173 <+78>:    mov    edx,eax
   0x0000000000001175 <+80>:    mov    rcx,QWORD PTR [rbp-0x120]
   0x000000000000117c <+87>:    lea    rax,[rbp-0x100]
   0x0000000000001183 <+94>:    mov    rsi,rcx
   0x0000000000001186 <+97>:    mov    rdi,rax
   0x0000000000001189 <+100>:   call   0x118e



   0x0000000000001125 <+0>:     push   rbp
   0x0000000000001126 <+1>:     mov    rbp,rsp
   0x0000000000001129 <+4>:     push   r12
   0x000000000000112b <+6>:     push   rbx
   0x000000000000112c <+7>:     sub    rsp,0x120
   0x0000000000001133 <+14>:    mov    QWORD PTR [rbp-0x108],rdi
   0x000000000000113a <+21>:    mov    QWORD PTR [rbp-0x110],rsi
   0x0000000000001141 <+28>:    mov    QWORD PTR [rbp-0x120],rdx
   0x0000000000001148 <+35>:    mov    QWORD PTR [rbp-0x118],rcx
   0x000000000000114f <+42>:    mov    QWORD PTR [rbp-0x128],r8
   0x0000000000001156 <+49>:    mov    QWORD PTR [rbp-0x130],r9
   0x000000000000115d <+56>:    lea    rax,[rbp-0x100]
   0x0000000000001164 <+63>:    mov    rdi,rax
   0x0000000000001167 <+66>:    call   0x116c
   0x000000000000116c <+71>:    mov    rax,QWORD PTR [rbp-0x118]
   0x0000000000001173 <+78>:    mov    edx,eax
   0x0000000000001175 <+80>:    mov    rcx,QWORD PTR [rbp-0x120]
   0x000000000000117c <+87>:    lea    rax,[rbp-0x100]
   0x0000000000001183 <+94>:    mov    rsi,rcx
   0x0000000000001186 <+97>:    mov    rdi,rax
   0x0000000000001189 <+100>:   call   0x118e



然而，在 GCC-8/9/10 中，程序集变成


所以逻辑几乎相同，移位量改变了？我觉得这种行为太奇怪了。


参数列表类似于：


我也倾倒了堆栈 x/-100xg $rbp


现在，这似乎0x00007ffebbd1ddb0是第一个参数的正确值，但 C++ 将其读为0x00007fe7a5e01080




更新：


在 callq 之后，在执行之前push %rbp：


这是我从x/-100xg $rsp($rsp = 0x7fff0b7d4338) 得到的


和100xg：


的帧信息C++：


预期的第一个参数： 0x7fffffffbfe0


预期的第二个参数： (0x7fff0ae01080, 0x3e)


预期的第三个参数： 0x3b


预期的第四个参数： (0x7fff0ae2f4e0, 1)


预期第 5、第 6 个参数：7、6




回答




较新的 GCCpush在函数顶部执行的操作少了一个（调用保留的寄存器少了一个）。因此，它只需要将 RSP 移动 8 的偶数倍（0x120）即可在下一次调用之前到达 16 字节对齐边界，同时保留足够的空间，而不是 0x128。


这两件事都会改变 RBP 和 RSP 之间的距离，从而改变[RBP-0x130]到达 RSP 正上方空间所需的偏移量，以便在堆栈上按值传递大型结构。


我没有检查数学，但是如果您仍然认为 GCC 可能存在正确性错误，您可以再次检查自己。




struct View只有两个指针大小的成员。因此，x86-64 System V ABI 可以在一对寄存器中传递它。


它没有构造函数或析构函数，或其他任何东西，所以 C++ ABI 随之而来。（我忘记了用于确定对象是否必须具有地址并因此将其传递到堆栈上的确切规则。如果您的 C++ 与 Rust 代码不


0x7fff0b7d4108: 0x00007fff0ae01080      0x000000000000003e
0x7fff0b7d4118: 0x0000003e00000060      0x00007fff0b7d4ab8
0x7fff0b7d4128: 0x00007fff0b7d4310      0x00007fff0b7d4310
0x7fff0b7d4138: 0x00007fff00000004      0x00007fff0b7d41b8
0x7fff0b7d4148: 0x00007fff0ae2f480      0x00007fff00000004
0x7fff0b7d4158: 0x00007fff0b7d41b8      0x00007fff0ae2f480
0x7fff0b7d4168: 0x0000000000000004      0x0000000000000000
0x7fff0b7d4178: 0x00007fff0b7d41b8      0x00007fff0ae2f498
0x7fff0b7d4188: 0x0000000000000000      0x00007fff0ae2f498
0x7fff0b7d4198: 0x00007ffff3d8219e      0x00007fff0b7d41b8
0x7fff0b7d41a8: 0x00007ffff3da157f      0x00007fff0ae01080
0x7fff0b7d41b8: 0x000000000000003e      0x000000000000003e
0x7fff0b7d41c8: 0x0000000000000002      0x000000000000003e
0x7fff0b7d41d8: 0x00007ffff5d4326d      0x00007fff0ae01080
0x7fff0b7d41e8: 0x000000000000003e      0x00007fff0b7d41b0
0x7fff0b7d41f8: 0x00007fff0ae01080      0x000000000000003e
0x7fff0b7d4208: 0x000000000000003e      0x0000000000000004
0x7fff0b7d4218: 0x00007fff0ae2f480      0x00007fff0ae2f498
0x7fff0b7d4228: 0x0000000000000004      0x00007fff0ae2f480
0x7fff0b7d4238: 0x00007fff0ae2f498      0x00007fff0ae2f480
0x7fff0b7d4248: 0x0000000000000004      0x0000000000000001
0x7fff0b7d4258: 0x00007fff0b7fe2a8      0x00007fff0ae2f480
0x7fff0b7d4268: 0x0000000000000004      0x00007fff0ae2f498
0x7fff0b7d4278: 0x00007fff0ae2f498      0x00007fff0ae2f4e0
0x7fff0b7d4288: 0x0000000000000000      0x00007fff0ae2f4e0
0x7fff0b7d4298: 0x00007ffff3e270ed      0x00007fff0b7d42f8
0x7fff0b7d42a8: 0x00007fff0ae2f4e0      0x00007fff0ae2f4e0
0x7fff0b7d42b8: 0x00007ffff3d99f42      0x00007fff0ae2f4e0
0x7fff0b7d42c8: 0x00007fff0b7d43f0      0x00007fff0b7d43f0
0x7fff0b7d42d8: 0x00007ffff3dc3a04      0x0000000000000001
0x7fff0b7d42e8: 0x0000000000000001      0x00007fff0b7d43f0
0x7fff0b7d42f8: 0x00007fff0ae2f4e0      0x00007fff0ae2f4e0
0x7fff0b7d4308: 0x0000000000000001      0x00007fff0b7d43f0
0x7fff0b7d4318: 0x00007ffff3d931cf      0x00007fff0ae2f4e0
0x7fff0b7d4328: 0x0000000000000001      0x00007fff0b7d43f0



同意这一点，则可能导致


0x7fff0b7d4338: 0x00007ffff3dc42fe      0x0000000000000007
0x7fff0b7d4348: 0x0000000000000006      0x00007ffff637393e
0x7fff0b7d4358: 0x00007fff0ae2f480      0x00007fff0b7d4388
0x7fff0b7d4368: 0x00007fff0ae2f480      0x0000000000000060
0x7fff0b7d4378: 0x00007fff0ae01080      0x000000000000003e
0x7fff0b7d4388: 0x0000000000000001      0x00007fff0ae2f4e0
0x7fff0b7d4398: 0x000000000000003e      0x00007fff0ae01080
0x7fff0b7d43a8: 0x0000000013bd0d88      0x00007fffffffbfe0
0x7fff0b7d43b8: 0x00007fff0b7d4420      0x00007fffffffbfa8
0x7fff0b7d43c8: 0x00007fffffffbf50      0x00007fff0b7d4ab8
0x7fff0b7d43d8: 0x000000000000003b      0x0000000000000007
0x7fff0b7d43e8: 0x0000000000000006      0x00007fff0ae2f4e0
0x7fff0b7d43f8: 0x0000000000000004      0x0000000000000001
0x7fff0b7d4408: 0x00007fff0ae2f480      0x0000000000000004
0x7fff0b7d4418: 0x0000000000000001      0x00007fff0ae01080
0x7fff0b7d4428: 0x000000000000003e      0x000000000000003e
0x7fff0b7d4438: 0x00007fffffffbf50      0x00007fff0b7d4ab8
0x7fff0b7d4448: 0x000000000000003b      0x0000000000000007
0x7fff0b7d4458: 0x0000000000000006      0x00007fff0ae2f2a0
0x7fff0b7d4468: 0x000000000000003e      0x00007fff0ae01080
0x7fff0b7d4478: 0x000000000000003e      0x00007fff0ae2f4e0
0x7fff0b7d4488: 0x0000000000000001      0x00007fff0b7d45b0
0x7fff0b7d4498: 0x000001ff0ae2f2a0      0x00007fff0ae2f480
0x7fff0b7d44a8: 0x0000000000000000      0x00007ffff7bb2c60
0x7fff0b7d44b8: 0x00007ffff3daebc6      0x0000000000201000
0x7fff0b7d44c8: 0x0000000000000000      0x00007fffebd4f080
0x7fff0b7d44d8: 0x00007fff0ae2f2a0      0x000000000000003e
0x7fff0b7d44e8: 0x0100000000010301      0x00007fff0ae2f2a0
0x7fff0b7d44f8: 0x000000000000003e      0x000000000000003e
0x7fff0b7d4508: 0x00007fff0ae2f2a0      0x000000000000003e
0x7fff0b7d4518: 0x00007fff0ae2f2a0      0x000000000000003e
0x7fff0b7d4528: 0x00007fff0ae2f2a0      0x0000000060cc0baf
0x7fff0b7d4538: 0x00007fff0ae32180      0x00007fffffffbf50
0x7fff0b7d4548: 0x0000000000000000      0x00007fff0ae32240
0x7fff0b7d4558: 0x00007fff0ae32000      0x0000000000000006
0x7fff0b7d4568: 0x0000000000000007      0x000000000000003b
0x7fff0b7d4578: 0x00007fff0ae3e000      0x00007fff0b7d50b0
0x7fff0b7d4588: 0x00007fff0b7d50b0      0x00007fff0b7d4ab8
0x7fff0b7d4598: 0x00007fff0ae2f480      0x0000000000000004
0x7fff0b7d45a8: 0x0000000000000001      0x00007fff0ae32240
0x7fff0b7d45b8: 0x00007fff0ae32240      0x0000000000000000
0x7fff0b7d45c8: 0x00007fff0ae2f2a0      0x000000000000003e
0x7fff0b7d45d8: 0x0000000000000001      0x00007fff0ae2f480
0x7fff0b7d45e8: 0x0000000000000004      0x0000000000000001
0x7fff0b7d45f8: 0x0000000000000000      0x00007fff0ae3e000
0x7fff0b7d4608: 0x000000000000003b      0x0000000000000007
0x7fff0b7d4618: 0x0000000000000006      0x00007fffebda59d0
0x7fff0b7d4628: 0x00007ffff21bf5cd      0x00007fff0ae32180
0x7fff0b7d4638: 0x00007fff0ae32180      0x00007fff0ae32180
0x7fff0b7d4648: 0x0000000000000000      0x00007fff0b7d4858



他们不同意如何传递它。）


 called by frame at 0x7fff0b7d44c0
 source language c++.
 Arglist at 0x7fff0b7d4330, args: server=0x7fff0ae2f498, region_buff=..., peer_id=62, snaps=..., index=62, term=140737324202302
 Locals at 0x7fff0b7d4330, Previous frame's sp is 0x7fff0b7d4340
 Saved registers:
  rip at 0x7fff0b7d4338



更新，因为问题确实是一个非平凡的结构：


    

  • -fabi-version选项的GCC 手册：
    • 





版本 12 首次出现在 G++ 8 中，更正了 x86_64 目标上的空类和仅删除复制/移动构造函数的类的调用约定。它意外地更改了具有已删除复制构造函数和微不足道的移动构造函数的类的调用约定。


版本 13 首次出现在 G++ 8.2 中，修复了版本 12 中的意外更改。






因此，前 6 个 args（将结构计为两个 args）将在 RDI、RSI、RDX、RCX、R8、R10（按此顺序）中传递，其余在堆栈中。您可以编写一个简单的函数来查看它在何处查找 args：


GCC-Og -fverbose-asm在Godbolt 上制作了以下 asm，GCC11：


（index因此，您可以看到第一个堆栈 arg，就在返回地址的正上方；较早的堆栈 arg 在寄存器中。  snaps.len是 R9 中的最后一个寄存器 arg。）


我猜uint64_t是你的 ReturnType。如果它是一个大于 2 个寄存器的结构，那么您将有一个指向返回值对象的指针作为 RDI 中的第一个 arg，而其他 args 则增加了 1。




您的转储与您预期的参数匹配就好了。  我重新格式化了它，以便我可以向每个 qword（8 字节）堆栈槽添加注释。


较早的 args 都在寄存器中。


如果调试信息没有完美地找到它们，那可能是因为您进行了优化编译；事情变得棘手，被调用者可能不会在任何地方保留其传入参数的副本。或者即使没有，获得正确的调试信息也可能很棘手。




    





int ffi_function(Opaque *server, View region_buf, uint64_t peer_id,
                View snaps, uint64_t index, uint64_t term)
{
    //return region_buf.len;
    return region_buf.len - snaps.len + index;
}



ffi_function(Opaque*, View, unsigned long, View, unsigned long, unsigned long):
        sub     rdx, r9   # _3, tmp103
        mov     rax, rdx  # _3, _3
        add     rax, QWORD PTR [rsp+8]    # _3, index
        ret



RSP:
0x7fff0b7d4338: 0x00007ffff3dc42fe (return addr)
                0x0000000000000007 (expected 5th arg = 7)
                0x0000000000000006 (expected 6th arg = 6)
                0x00007ffff637393e (part of the caller's stack frame, not args)
                ...
以上是为什么GCC8/9/10和GCC-7在计算堆栈偏移量时表现不同？的全部内容。
THE END
分享
二维码
< <上一篇
下一篇>>