2023-07-22 08:22:53 +08:00
[#]: subject: "How the GDB debugger and other tools use call frame information to determine the active function calls"
[#]: via: "https://opensource.com/article/23/3/gdb-debugger-call-frame-active-function-calls"
[#]: author: "Will Cohen https://opensource.com/users/wcohen"
[#]: collector: "lkxed"
[#]: translator: "jrglinux"
2023-07-26 06:27:11 +08:00
[#]: reviewer: "wxy"
[#]: publisher: "wxy"
[#]: url: "https://linux.cn/article-16033-1.html"
2023-07-22 08:22:53 +08:00
2023-07-26 06:27:11 +08:00
GDB 调试器如何通过调用帧信息来确定函数调用关系
2023-07-22 08:22:53 +08:00
======
2023-07-26 06:27:11 +08:00
![][0]
2023-07-22 08:22:53 +08:00
2023-07-26 06:27:11 +08:00
> 从调试器中获取函数调用关系。
在我的 [上一篇文章][1] 中，我展示了如何使用 `debuginfo` 在当前指令指针（ ）
例如，将空指针作为参数传递到函数中而导致非法内存访问的问题，只需查看当前执行函数行，即可发现该错误是由尝试通过空指针进行访问而触发的。但是，你真正想知道的是导致空指针访问的函数调用的完整上下文，以便确定该空指针最初是如何传递到该函数中的。此上下文信息由回溯提供，可以让你确定哪些函数可能对空指针参数负责。
2023-07-22 08:22:53 +08:00
有一点是肯定的：确定当前活动的函数调用栈不是一项简单的操作。
### 函数激活记录
2023-07-26 06:27:11 +08:00
现代编程语言具有局部变量，并允许函数可以调用自身的递归。此外，并发程序具有多个线程，这些线程可能同时运行相同的函数。在这些情况下，局部变量不能存储在全局位置。对于函数的每次调用，局部变量的位置必须是唯一的。它的工作原理如下：
2023-07-22 08:22:53 +08:00
- 每次调用函数时，编译器都会生成函数激活记录，以将局部变量存储在唯一位置。
- 为了提高效率，处理器堆栈用于存储函数激活记录。
- 当函数被调用时，会在处理器堆栈的顶部为该函数创建一条新的函数激活记录。
- 如果该函数调用另一个函数，则新的函数激活记录将放置在现有函数激活记录之上。
- 每次函数返回时，其函数激活记录都会从堆栈中删除。
2023-07-26 06:27:11 +08:00
函数激活记录的创建是由函数中称为“< ruby > 序言< rt > prologue< / rt > < / ruby > ”的代码创建的。函数激活记录的删除由函数“< ruby > 尾声< rt > epilogue< / rt > < / ruby > ”处理。函数体可以利用堆栈上为其预留的内存来存储临时值和局部变量。
2023-07-22 08:22:53 +08:00
2023-07-26 06:27:11 +08:00
函数激活记录的大小可以是可变的。对于某些函数，不需要空间来存储局部变量。理想情况下，函数激活记录只需要存储调用 _该_ 函数的函数的返回地址。对于其他函数，除了返回地址之外，可能还需要大量空间来存储函数的本地数据结构。帧大小的可变导致编译器使用帧指针来跟踪函数激活帧的开始。函数序言代码具有在为当前函数创建新帧指针之前存储旧帧指针的额外任务，并且函数尾声必须恢复旧帧指针值。
2023-07-22 08:22:53 +08:00
2023-07-26 06:27:11 +08:00
函数激活记录的布局方式、调用函数的返回地址和旧帧指针是相对于当前帧指针的恒定偏移量。通过旧的帧指针，可以定位堆栈上下一个函数的激活帧。重复此过程，直到检查完所有函数激活记录为止。
2023-07-22 08:22:53 +08:00
### 优化复杂性
2023-07-26 06:27:11 +08:00
在代码中使用显式帧指针有几个缺点。在某些处理器上，可用的寄存器相对较少。具有显式帧指针会导致使用更多内存操作。生成的代码速度较慢，因为帧指针必须位于寄存器中。具有显式帧指针可能会限制编译器可以生成的代码，因为编译器可能不会将函数序言和尾声代码与函数体混合。
2023-07-22 08:22:53 +08:00
2023-07-26 06:27:11 +08:00
编译器的目标是尽可能生成快速代码，因此编译器通常会从生成的代码中省略帧指针。正如 [Phoronix 的基准测试][2] 所示，保留帧指针会显着降低性能。不过省略帧指针也有缺点，查找前一个调用函数的激活帧和返回地址不再是相对于帧指针的简单偏移。
2023-07-22 08:22:53 +08:00
### 调用帧信息
2023-07-26 06:27:11 +08:00
为了帮助生成函数回溯，编译器包含 DWARF 调用帧信息（ ） `.eh_frame` 部分中。与传统的函数和行位置信息的 `debuginfo` 不同，即使生成的可执行文件没有调试信息，或者调试信息已从文件中删除，`.eh_frame` 部分也位于可执行文件中。 调用帧信息对于 C++ 中的 `throw-catch` 等语言结构的操作至关重要。
2023-07-22 08:22:53 +08:00
2023-07-26 06:27:11 +08:00
CFI 的每个功能都有一个帧描述条目（ ） ，
2023-07-22 08:22:53 +08:00
- 规范帧地址（ ） ，
- 返回地址
- 有关其他寄存器的信息
2023-07-26 06:27:11 +08:00
FDE 的编码旨在最大限度地减少所需的空间量。FDE 描述了行之间的变化，而不是完全指定每一行。为了进一步压缩数据，多个 FDE 共有的起始信息被分解出来并放置在通用信息条目（ ） ， ，
2023-07-22 08:22:53 +08:00
### 调用帧信息使用实例
从一个简单的示例开始，其中包含将华氏温度转换为摄氏度的函数。 内联函数在 CFI 中没有条目，因此 `f2c` 函数的 `__attribute__((noinline))` 确保编译器将 `f2c` 保留为真实函数。
```
#include <stdio.h>
int __attribute__ ((noinline)) f2c(int f)
{
int c;
printf("converting\n");
c = (f-32.0) * 5.0 /9.0;
return c;
}
int main (int argc, char *argv[])
{
int f;
scanf("%d", &f);
printf ("%d Fahrenheit = %d Celsius\n",
f, f2c(f));
return 0;
}
```
编译代码：
```
$ gcc -O2 -g -o f2c f2c.c
```
2023-07-26 06:27:11 +08:00
`.eh_frame` 部分展示如下:
2023-07-22 08:22:53 +08:00
```
$ eu-readelf -S f2c |grep eh_frame
[17] .eh_frame_hdr PROGBITS 0000000000402058 00002058 00000034 0 A 0 0 4
[18] .eh_frame PROGBITS 0000000000402090 00002090 000000a0 0 A 0 0 8
```
我们可以通过以下方式获取 CFI 信息：
```
$ readelf --debug-dump=frames f2c > f2c.cfi
```
生成 `f2c` 可执行文件的反汇编代码，这样你可以查找 `f2c` 和 `main` 函数：
```
$ objdump -d f2c > f2c.dis
```
在 `f2c.dis` 中找到以下信息来看看 `f2c` 和 `main` 函数的执行位置：
```
0000000000401060 < main > :
0000000000401190 < f2c > :
```
在许多情况下，二进制文件中的所有函数在执行函数的第一条指令之前都使用相同的 CIE 来定义初始条件。 在此示例中， `f2c` 和 `main` 都使用以下 CIE：
```
00000000 0000000000000014 00000000 CIE
Version: 1
Augmentation: "zR"
Code alignment factor: 1
Data alignment factor: -8
Return address column: 16
Augmentation data: 1b
DW_CFA_def_cfa: r7 (rsp) ofs 8
DW_CFA_offset: r16 (rip) at cfa-8
DW_CFA_nop
DW_CFA_nop
```
2023-07-26 06:27:11 +08:00
本示例中，不必担心增强或增强数据条目。由于 x86_64 处理器具有 1 到 15 字节大小的可变长度指令，因此 “代码对齐因子” 设置为 1。在只有 32 位（ ， ，
2023-07-22 08:22:53 +08:00
2023-07-26 06:27:11 +08:00
虚拟表中保存返回地址的列是 16。这在 CIE 尾部的指令中使用。 有四个 `DW_CFA` 指令。第一条指令 `DW_CFA_def_cfa` 描述了如果代码具有帧指针， （ ） ， `r7 (rsp)` 和 `CFA=rsp+8` 计算的。
2023-07-22 08:22:53 +08:00
2023-07-26 06:27:11 +08:00
第二条指令 `DW_CFA_offset` 定义从哪里获取返回地址 `CFA-8` 。在这种情况下，返回地址当前由堆栈指针 `(rsp+8)-8` 指向。CFA 从堆栈返回地址的正上方开始。
2023-07-22 08:22:53 +08:00
CIE 末尾的 `DW_CFA_nop` 进行填充以保持 DWARF 信息的对齐。 FDE 还可以在末尾添加填充以进行对齐。
在 `f2c.cfi` 中找到 `main` 的 FDE， `0x40160` 到（但不包括）`0x401097` 的 `main` 函数：
```
00000084 0000000000000014 00000088 FDE cie=00000000 pc=0000000000401060..0000000000401097
DW_CFA_advance_loc: 4 to 0000000000401064
DW_CFA_def_cfa_offset: 32
DW_CFA_advance_loc: 50 to 0000000000401096
DW_CFA_def_cfa_offset: 8
DW_CFA_nop
```
2023-07-26 06:27:11 +08:00
在执行函数中的第一条指令之前， `DW_CFA_advance_loc` 和 `DW_CFA_def_cfa_offset` 与 `main` 中 `401060` 处的第一条指令匹配。 这会将堆栈指针向下调整 `0x18` （ `401064` 处的正确计算是 `rsp+32` 。 这就是这段代码中序言指令的范围。 以下是 `main` 中的前几条指令：
2023-07-22 08:22:53 +08:00
```
0000000000401060 < main > :
401060: 48 83 ec 18 sub $0x18,%rsp
401064: bf 1b 20 40 00 mov $0x40201b,%edi
```
2023-07-26 06:27:11 +08:00
`DW_CFA_advance_loc` 使当前行应用于函数中接下来的 50 个字节的代码，直到 `401096` 。CFA 位于 `rsp+32` ，直到 `401092` 处的堆栈调整指令完成执行。`DW_CFA_def_cfa_offset` 将 CFA 的计算更新为与函数入口相同。这是预期之中的，因为 `401096` 处的下一条指令是返回指令 `ret` ，并将返回值从堆栈中弹出。
2023-07-22 08:22:53 +08:00
```
401090: 31 c0 xor %eax,%eax
401092: 48 83 c4 18 add $0x18,%rsp
401096: c3 ret
```
`f2c` 函数的 FDE 使用与 `main` 函数相同的 CIE， `0x41190` 到 `0x4011c3` 的范围：
```
00000068 0000000000000018 0000006c FDE cie=00000000 pc=0000000000401190..00000000004011c3
DW_CFA_advance_loc: 1 to 0000000000401191
DW_CFA_def_cfa_offset: 16
DW_CFA_offset: r3 (rbx) at cfa-16
DW_CFA_advance_loc: 29 to 00000000004011ae
DW_CFA_def_cfa_offset: 8
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
```
可执行文件中 `f2c` 函数的 `objdump` 输出：
```
0000000000401190 < f2c > :
401190: 53 push %rbx
401191: 89 fb mov %edi,%ebx
401193: bf 10 20 40 00 mov $0x402010,%edi
401198: e8 93 fe ff ff call 401030 < puts @ plt >
40119d: 66 0f ef c0 pxor %xmm0,%xmm0
4011a1: f2 0f 2a c3 cvtsi2sd %ebx,%xmm0
4011a5: f2 0f 5c 05 93 0e 00 subsd 0xe93(%rip),%xmm0 # 402040 < __dso_handle + 0x38 >
4011ac: 00
4011ad: 5b pop %rbx
4011ae: f2 0f 59 05 92 0e 00 mulsd 0xe92(%rip),%xmm0 # 402048 < __dso_handle + 0x40 >
4011b5: 00
4011b6: f2 0f 5e 05 92 0e 00 divsd 0xe92(%rip),%xmm0 # 402050 < __dso_handle + 0x48 >
4011bd: 00
4011be: f2 0f 2c c0 cvttsd2si %xmm0,%eax
4011c2: c3 ret
```
在 `f2c` 的 FDE 中，函数开头有一个带有 `DW_CFA_advance_loc` 的单字节指令。在高级操作之后，还有两个附加操作。`DW_CFA_def_cfa_offset` 将 CFA 更改为 `%rsp+16` ， `%rbx` 中的初始值现在位于 `CFA-16` （堆栈顶部）。
2023-07-26 06:27:11 +08:00
查看这个 `fc2` 反汇编代码，可以看到 `push` 用于将 `%rbx` 保存到堆栈中。 在代码生成中省略帧指针的优点之一是可以使用 `push` 和 `pop` 等紧凑指令在堆栈中存储和检索值。 在这种情况下，保存 `%rbx` 是因为 `%rbx` 用于向 `printf` 函数传递参数（实际上转换为 `puts` 调用），但需要保存传递到函数中的 `f` 初始值以供后面的计算使用。`4011ae` 的 `DW_CFA_advance_loc` 29字节显示了 `pop %rbx` 之后的下一个状态变化，它恢复了 `%rbx` 的原始值。 `DW_CFA_def_cfa_offset` 指出 pop 将 CFA 更改为 `%rsp+8` 。
2023-07-22 08:22:53 +08:00
2023-07-26 06:27:11 +08:00
### GDB 使用调用帧信息
2023-07-22 08:22:53 +08:00
2023-07-26 06:27:11 +08:00
有了 CFI 信息，[GNU 调试器（ ） ， `f2c.c` 的第 7 行设置断点，可以看到 GDB 使用此信息。GDB在 `f2c` 函数中的 `pop %rbx` 完成且返回值不在栈顶之前放置了断点。
2023-07-22 08:22:53 +08:00
GDB 能够展开堆栈，并且作为额外收获还能够获取当前保存在堆栈上的参数 `f` ：
```
$ gdb f2c
[...]
(gdb) break f2c.c:7
Breakpoint 1 at 0x40119d: file f2c.c, line 7.
(gdb) run
Starting program: /home/wcohen/present/202207youarehere/f2c
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
98
converting
Breakpoint 1, f2c (f=98) at f2c.c:8
8 return c;
(gdb) where
#0 f2c (f=98) at f2c.c:8
#1 0x000000000040107e in main (argc=<optimized out>, argv=<optimized out>)
at f2c.c:15
```
### 调用帧信息
DWARF 调用帧信息为编译器提供了一种灵活的方式来包含用于准确展开堆栈的信息。这使得可以确定当前活动的函数调用。我在本文中提供了简要介绍，但有关 DWARF 如何实现此机制的更多详细信息，请参阅 [DWARF 规范][4]。
2023-07-26 06:27:11 +08:00
*（ ： ）
2023-07-22 08:22:53 +08:00
--------------------------------------------------------------------------------
via: https://opensource.com/article/23/3/gdb-debugger-call-frame-active-function-calls
作者：[Will Cohen][a]
选题：[lkxed][b]
译者：[jrglinux](https://github.com/jrglinux)
2023-07-26 06:27:11 +08:00
校对：[wxy](https://github.com/wxy)
2023-07-22 08:22:53 +08:00
本文由 [LCTT ](https://github.com/LCTT/TranslateProject ) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/wcohen
[b]: https://github.com/lkxed/
[1]: https://opensource.com/article/23/2/compiler-optimization-debugger-line-information
[2]: https://www.phoronix.com/review/fedora-frame-pointer
[3]: https://opensource.com/article/21/3/debug-code-gdb
[4]: https://dwarfstd.org/Download.php
2023-07-26 06:27:11 +08:00
[0]: https://img.linux.net.cn/data/attachment/album/202307/26/062542j0picgf1fs6nd8qn.jpg
