问题描述
我正在将代码移植到现代编译器，但不幸的是，当从 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
然而，在 GCC-8/9/10 中，程序集变成了
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
所以逻辑几乎是一样的，移位量改变了？我觉得这种行为太奇怪了。
参数列表类似于：
struct Opaque {
char _inner[0];
}
struct View {
char * base;
size_t len;
}
ReturnType ffi_function(Opaque*,View,uint64_t,uint64_t);
我还通过 x/-100xg $rbp
0x7fe7a67d41c0: 0x00007fe7a67d41f0 0x0000000014c1b1dc
0x7fe7a67d41d0: 0x000000000000003e 0x0000000000000006
0x7fe7a67d41e0: 0x00007fe7a67d4330 0x00007fe88714b540
0x7fe7a67d41f0: 0x0000000000201000 0x0000000013bd0df1
0x7fe7a67d4200: 0x0000000000000001 0x00007fe7a5e2f4e0
0x7fe7a67d4210: 0x000000000000003e 0x000000000000003b
0x7fe7a67d4220: 0x00007fe7a5e01080 0x00007ffebbd1ddb0
0x7fe7a67d4230: 0x000000001602ff80 0x0000000000000000
0x7fe7a67d4240: 0x0000000000000000 0x0000000000000000
0x7fe7a67d4250: 0x0000000000000000 0x0000000018d59680
0x7fe7a67d4260: 0x0000000018d59680 0x0000000000000000
0x7fe7a67d4270: 0x0000000000000000 0x0000000000000000
0x7fe7a67d4280: 0x00007fe700000000 0x0000000000000000
0x7fe7a67d4290: 0x00007fe7a5e2f4e0 0x00007fe88f1630ed
0x7fe7a67d42a0: 0x00007fe7a67d42f8 0x00007fe7a5e2f4e0
0x7fe7a67d42b0: 0x00007fe7a5e2f4e0 0x00007fe88f0d5f42
0x7fe7a67d42c0: 0x00007fe7a5e2f4e0 0x00007fe7a67d43f0
0x7fe7a67d42d0: 0x00007fe7a67d43f0 0x00007fe88f0ffa04
0x7fe7a67d42e0: 0x0000000000000001 0x0000000000000001
0x7fe7a67d42f0: 0x00007fe7a67d43f0 0x00007fe7a5e2f4e0
0x7fe7a67d4300: 0x00007fe7a5e2f4e0 0x0000000000000001
0x7fe7a67d4310: 0x00007fe7a67d43f0 0x00007fe88f0cf1cf
0x7fe7a67d4320: 0x0000000000000006 0x00007fe88714b540
现在，似乎 0x00007ffebbd1ddb0 是第一个参数的正确值，但 C++ 将其读作 0x00007fe7a5e01080
更新：
就在 callq 之后，执行 push %rbp 之前：
这是我从 x/-100xg $rsp ($rsp = 0x7fff0b7d4338) 得到的
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
和100xg：
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
C++ 的帧信息：
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
预期的第一个参数：0x7fffffffbfe0
预期的第二个参数：(0x7fff0ae01080,0x3e)
预期的第三个参数：0x3b
预期的第 4 个参数：(0x7fff0ae2f4e0,1)
预期的第 5 个、第 6 个参数：7、6
解决方法
较新的 GCC 在函数顶部少执行一个 push（少保存一个调用保留寄存器）。所以它只需要将 RSP 移动 8 的偶数倍（0x120）即可在下一次调用之前到达 16 字节对齐边界，同时保留足够的空间，而不是 0x128。
这两种情况都会改变 RBP 和 RSP 之间的距离，因此需要 [RBP-0x130] 偏移量才能到达 RSP 正上方的空间以在堆栈上按值传递大型结构体。
我没有检查数学，但如果您仍然认为 GCC 可能存在正确性错误，您可以再次检查自己。
struct View 只有两个指针大小的成员。因此，x86-64 System V ABI 可以在一对寄存器中传递它。
而且它没有构造函数或析构函数或其他任何东西，所以 C++ ABI 也随之而来。 （我忘记了用于决定对象是否必须具有地址并因此将其传递到堆栈上的确切规则。如果您的 C++ 与 Rust 代码不同意这一点，可能会导致他们不同意如何传递它。）>
更新，因为问题确实是一个非平凡的结构：
首次出现在 G++ 8 中的版本 12 更正了 x86_64 目标上的空类和仅删除复制/移动构造函数的类的调用约定。它意外地更改了具有删除的复制构造函数和微不足道的移动构造函数的类的调用约定。
首次出现在 G++ 8.2 中的第 13 版修复了第 12 版中的意外更改。
因此，前 6 个参数（将结构计为两个参数）将在 RDI、RSI、RDX、RCX、R8、R10（按此顺序）中传递，其余在堆栈中。您可以编写一个简单的函数来查看它在何处查找 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;
}
GCC -Og -fverbose-asm makes the following asm，Godbolt 上的 GCC11：
ffi_function(Opaque*,View,unsigned long,unsigned long):
sub rdx,r9 # _3,tmp103
mov rax,rdx # _3,_3
add rax,QWORD PTR [rsp+8] # _3,index
ret
（因此您可以看到 index 是第一个堆栈参数，就在返回地址的正上方；较早的堆栈参数在寄存器中。snaps.len 是 R9 中的最后一个寄存器参数。）
我猜 uint64_t 是您的 ReturnType。如果它是一个大于 2 个寄存器的结构体，那么您将有一个指向返回值对象的指针作为 RDI 中的第一个 arg，而其他 args 则增加 1。
您的转储与您预期的参数匹配得很好。我重新格式化了它，以便我可以向每个 qword（8 字节）堆栈槽添加注释。
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)
...
前面的参数都在寄存器中。
如果调试信息没有完美地找到它们，那可能是因为您进行了优化编译；事情变得棘手，被调用者可能不会在任何地方保留其传入参数的副本。或者即使没有，让调试信息正常工作也很棘手。
,抱歉我的回复晚了。再次感谢@Peter Cordes。 我的一位同事终于找到并解决了这个问题。
事实证明，View 的定义并不完全是微不足道的。结构中添加了一个自定义构造函数。
我的同事做了两件事来解决这个问题：
- 删除所有构造函数以保持结构简单
- 将所有相关的 ffi 函数移至 extern C 范围。
我还没有查看生成的代码，但根据报告，段错误已经消失。
话虽如此，我仍然认为可能需要仔细考虑一些事情。如果我们严格遵循 Itanium ABI，可以看到 View 仍然是 trivial for the purpose of call
并且应该在 C 的约定中通过。
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#non-trivial-parameters
所以即使原来的代码有点“乱”，我觉得可以在FFI中使用吗？ （毕竟 gcc-7 在这方面做得很好，而且 -Wabi=11/12/13 没有向它抱怨）。
更新：
刚刚检查了程序集。更改后，gcc-10 生成与 gcc-7 完全相同的代码。