DMD 堆栈跟踪中的地址是什么意思？
What do the addresses in DMD stack traces mean?
我编译文件stacktrace.d：
void main(){assert(false);} 关闭 ASLR，当 运行ning 我得到：
core.exception.AssertError@stacktrace.d(2): Assertion failure
----------------
??:? _d_assertp [0x55586ed8]
??:? _Dmain [0x55586e20]
objdump -t stacktrace|grep _Dmain 给出
0000000000032e0c w F .text 0000000000000019 _Dmain
如果我 运行 gdb -q -nx -ex start -ex 'disas /rs _Dmain' -ex q stacktrace:
...
Dump of assembler code for function _Dmain:
0x0000555555586e0c <+0>: 55 push %rbp
0x0000555555586e0d <+1>: 48 8b ec mov %rsp,%rbp
=> 0x0000555555586e10 <+4>: be 02 00 00 00 mov [=11=]x2,%esi
0x0000555555586e15 <+9>: 48 8d 3d 44 c0 02 00 lea 0x2c044(%rip),%rdi # 0x5555555b2e60 <_TMP0>
0x0000555555586e1c <+16>: e8 47 00 00 00 callq 0x555555586e68 <_d_assertp>
0x0000555555586e21 <+21>: 31 c0 xor %eax,%eax
0x0000555555586e23 <+23>: 5d pop %rbp
0x0000555555586e24 <+24>: c3 retq
因此，即使前两个 0x55 字节只是 t运行 关闭，堆栈跟踪中给出的 0x...86e20 也不匹配指令的开始。
好的，我刚刚从评论中找到了证明我直觉的源代码部分。
这是添加时的 git 责备：https://github.com/dlang/druntime/blame/bc940316b4cd7cf6a76e34b7396de2003867fbef/src/core/runtime.d#L756
唉，提交消息不是很有用，但是代码本身，加上我的记忆，让我非常信服。
所以这是 druntime 库中的文件 core/runtime.d。在撰写本文时，它恰好在第 756 行
enum CALL_INSTRUCTION_SIZE = 1; // it may not be 1 but it is good enough to get
// in CALL instruction address range for backtrace
callstack[numframes++] = *(stackPtr + 1) - CALL_INSTRUCTION_SIZE;
请注意，那里的 callstack 变量会在抛出异常时复制当前调用。当请求实际写出时，跟踪打印机将查看该数组以确定要写入的内容。 （看，查找调试信息以打印 file/line 数字和函数名称真的很慢，所以它只在必须时这样做，以保持正常的异常使用 - 当它被抛出并稍后捕获时 - 更快。 )
无论如何，我记得回溯用于打印错误行的时候。它会打印包含下一条指令的代码行——这在源代码中可能与实际的 assert/throw 语句有相当大的距离，从而使打印的帮助不大。如果您查看 git blame link，您会看到旧代码用于直接复制堆栈中的地址。
call指令的工作原理是将return地址压入堆栈，然后跳转到子程序地址。 return 地址紧接 在 调用指令之后，因此当 CPU 返回那里时，它不会再次 运行 调用。这就是为什么旧代码会显示错误的行号，错误地归咎于以下指令。
新代码回退了一点地址，使其回到调用指令本身——从而将打印的函数放在它所属的行上。但是，在 x86 上，有一些不同的调用指令，我什至不确定是否 可能 正确倒回 - 您只能通过查看来确定指令的实际大小操作码，如果您知道指令的大小，或者像 cpu 本身那样按正向顺序读取代码，您就只知道操作码在哪里。此外，在其他处理器架构上，大小会有所不同。
就像该行中的评论所说的那样，我们实际上不必做到完美。此回溯的目标只是让用户查看正确的位置。调试信息使用一种边界框 - 如果您位于此函数或源代码行的起始地址或之后，但尚未位于下一个 function/line 的起始地址，它会认为您在那里。它不知道也不关心代码的小数行。
因此，它通过假设大小为 1 来极大地简化了实现 - 足以让它回到该边界。
我敢打赌 gdb 在内部做了类似的事情，只是它的打印机隐藏了这个，直接在它的回溯中显示来自堆栈的 return 地址。 （顺便说一句，有趣的提示：当 运行 在 gdb 中将它传递给程序的命令行参数时，将 --DRT-trapExceptions=no 传递给它。然后它会在程序仍然 运行ning 的情况下捕获抛出点，而不是打印消息并说程序以代码 1 退出！）
d运行time 打印代码也可以在打印前 +1 返回它以隐藏此内部实现 hack...但是嗯。 return 地址也不是调用实际发生的位置，无论如何，您都需要在反汇编程序中查看上面的内容。甚至 gdb 也不会实际显示调用地址（至少我的旧版本不会显示，也许新版本会显示）。但是，如果它在反汇编中是一个用于 grepping 的值，那可能会很好......如果你想对 d运行time 进行 PR，我会支持你（注意我在那里没有权限但是可以帮忙评论）。
但这至少明确地解释了现状。
我编译文件stacktrace.d：
void main(){assert(false);} 关闭 ASLR，当 运行ning 我得到：
core.exception.AssertError@stacktrace.d(2): Assertion failure
----------------
??:? _d_assertp [0x55586ed8]
??:? _Dmain [0x55586e20]
objdump -t stacktrace|grep _Dmain 给出
0000000000032e0c w F .text 0000000000000019 _Dmain
如果我 运行 gdb -q -nx -ex start -ex 'disas /rs _Dmain' -ex q stacktrace:
...
Dump of assembler code for function _Dmain:
0x0000555555586e0c <+0>: 55 push %rbp
0x0000555555586e0d <+1>: 48 8b ec mov %rsp,%rbp
=> 0x0000555555586e10 <+4>: be 02 00 00 00 mov [=11=]x2,%esi
0x0000555555586e15 <+9>: 48 8d 3d 44 c0 02 00 lea 0x2c044(%rip),%rdi # 0x5555555b2e60 <_TMP0>
0x0000555555586e1c <+16>: e8 47 00 00 00 callq 0x555555586e68 <_d_assertp>
0x0000555555586e21 <+21>: 31 c0 xor %eax,%eax
0x0000555555586e23 <+23>: 5d pop %rbp
0x0000555555586e24 <+24>: c3 retq
因此，即使前两个 0x55 字节只是 t运行 关闭，堆栈跟踪中给出的 0x...86e20 也不匹配指令的开始。
好的，我刚刚从评论中找到了证明我直觉的源代码部分。
这是添加时的 git 责备：https://github.com/dlang/druntime/blame/bc940316b4cd7cf6a76e34b7396de2003867fbef/src/core/runtime.d#L756
唉，提交消息不是很有用，但是代码本身，加上我的记忆，让我非常信服。
所以这是 druntime 库中的文件 core/runtime.d。在撰写本文时，它恰好在第 756 行
enum CALL_INSTRUCTION_SIZE = 1; // it may not be 1 but it is good enough to get
// in CALL instruction address range for backtrace
callstack[numframes++] = *(stackPtr + 1) - CALL_INSTRUCTION_SIZE;
请注意，那里的 callstack 变量会在抛出异常时复制当前调用。当请求实际写出时，跟踪打印机将查看该数组以确定要写入的内容。 （看，查找调试信息以打印 file/line 数字和函数名称真的很慢，所以它只在必须时这样做，以保持正常的异常使用 - 当它被抛出并稍后捕获时 - 更快。 )
无论如何，我记得回溯用于打印错误行的时候。它会打印包含下一条指令的代码行——这在源代码中可能与实际的 assert/throw 语句有相当大的距离，从而使打印的帮助不大。如果您查看 git blame link，您会看到旧代码用于直接复制堆栈中的地址。
call指令的工作原理是将return地址压入堆栈，然后跳转到子程序地址。 return 地址紧接 在 调用指令之后，因此当 CPU 返回那里时，它不会再次 运行 调用。这就是为什么旧代码会显示错误的行号，错误地归咎于以下指令。
新代码回退了一点地址，使其回到调用指令本身——从而将打印的函数放在它所属的行上。但是，在 x86 上，有一些不同的调用指令，我什至不确定是否 可能 正确倒回 - 您只能通过查看来确定指令的实际大小操作码，如果您知道指令的大小，或者像 cpu 本身那样按正向顺序读取代码，您就只知道操作码在哪里。此外，在其他处理器架构上，大小会有所不同。
就像该行中的评论所说的那样，我们实际上不必做到完美。此回溯的目标只是让用户查看正确的位置。调试信息使用一种边界框 - 如果您位于此函数或源代码行的起始地址或之后，但尚未位于下一个 function/line 的起始地址，它会认为您在那里。它不知道也不关心代码的小数行。
因此，它通过假设大小为 1 来极大地简化了实现 - 足以让它回到该边界。
我敢打赌 gdb 在内部做了类似的事情，只是它的打印机隐藏了这个，直接在它的回溯中显示来自堆栈的 return 地址。 （顺便说一句，有趣的提示：当 运行 在 gdb 中将它传递给程序的命令行参数时，将 --DRT-trapExceptions=no 传递给它。然后它会在程序仍然 运行ning 的情况下捕获抛出点，而不是打印消息并说程序以代码 1 退出！）
d运行time 打印代码也可以在打印前 +1 返回它以隐藏此内部实现 hack...但是嗯。 return 地址也不是调用实际发生的位置，无论如何，您都需要在反汇编程序中查看上面的内容。甚至 gdb 也不会实际显示调用地址（至少我的旧版本不会显示，也许新版本会显示）。但是，如果它在反汇编中是一个用于 grepping 的值，那可能会很好......如果你想对 d运行time 进行 PR，我会支持你（注意我在那里没有权限但是可以帮忙评论）。
但这至少明确地解释了现状。