TranslateProject/published/202307/20230310.1 ⭐️⭐️ How the GDB debugger and other tools use call frame information to determine the active function calls.md

[#]: 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"
[#]: reviewer: "wxy"
[#]: publisher: "wxy"
[#]: url: "https://linux.cn/article-16033-1.html"

GDB 调试器如何通过调用帧信息来确定函数调用关系
======

![][0]

> 从调试器中获取函数调用关系。

在我的 [上一篇文章][1] 中，我展示了如何使用 `debuginfo` 在当前指令指针（IP）和包含它的函数或行之间进行映射。该信息对于显示 CPU 当前正在执行的代码很有帮助。不过，如果能显示更多的有关当前函数调用栈及其正在执行语句的上下文对我们定位问题来说也是十分有助的。

例如，将空指针作为参数传递到函数中而导致非法内存访问的问题，只需查看当前执行函数行，即可发现该错误是由尝试通过空指针进行访问而触发的。但是，你真正想知道的是导致空指针访问的函数调用的完整上下文，以便确定该空指针最初是如何传递到该函数中的。此上下文信息由回溯提供，可以让你确定哪些函数可能对空指针参数负责。

有一点是肯定的：确定当前活动的函数调用栈不是一项简单的操作。

### 函数激活记录

现代编程语言具有局部变量，并允许函数可以调用自身的递归。此外，并发程序具有多个线程，这些线程可能同时运行相同的函数。在这些情况下，局部变量不能存储在全局位置。对于函数的每次调用，局部变量的位置必须是唯一的。它的工作原理如下：

- 每次调用函数时，编译器都会生成函数激活记录，以将局部变量存储在唯一位置。
- 为了提高效率，处理器堆栈用于存储函数激活记录。
- 当函数被调用时，会在处理器堆栈的顶部为该函数创建一条新的函数激活记录。
- 如果该函数调用另一个函数，则新的函数激活记录将放置在现有函数激活记录之上。
- 每次函数返回时，其函数激活记录都会从堆栈中删除。

函数激活记录的创建是由函数中称为“<ruby>序言<rt>prologue</rt></ruby>”的代码创建的。函数激活记录的删除由函数“<ruby>尾声<rt>epilogue</rt></ruby>”处理。函数体可以利用堆栈上为其预留的内存来存储临时值和局部变量。

函数激活记录的大小可以是可变的。对于某些函数，不需要空间来存储局部变量。理想情况下，函数激活记录只需要存储调用 _该_ 函数的函数的返回地址。对于其他函数，除了返回地址之外，可能还需要大量空间来存储函数的本地数据结构。帧大小的可变导致编译器使用帧指针来跟踪函数激活帧的开始。函数序言代码具有在为当前函数创建新帧指针之前存储旧帧指针的额外任务，并且函数尾声必须恢复旧帧指针值。

函数激活记录的布局方式、调用函数的返回地址和旧帧指针是相对于当前帧指针的恒定偏移量。通过旧的帧指针，可以定位堆栈上下一个函数的激活帧。重复此过程，直到检查完所有函数激活记录为止。

### 优化复杂性

在代码中使用显式帧指针有几个缺点。在某些处理器上，可用的寄存器相对较少。具有显式帧指针会导致使用更多内存操作。生成的代码速度较慢，因为帧指针必须位于寄存器中。具有显式帧指针可能会限制编译器可以生成的代码，因为编译器可能不会将函数序言和尾声代码与函数体混合。

编译器的目标是尽可能生成快速代码，因此编译器通常会从生成的代码中省略帧指针。正如 [Phoronix 的基准测试][2] 所示，保留帧指针会显着降低性能。不过省略帧指针也有缺点，查找前一个调用函数的激活帧和返回地址不再是相对于帧指针的简单偏移。

### 调用帧信息

为了帮助生成函数回溯，编译器包含 DWARF 调用帧信息（CFI）来重建帧指针并查找返回地址。此补充信息存储在执行的 `.eh_frame` 部分中。与传统的函数和行位置信息的 `debuginfo` 不同，即使生成的可执行文件没有调试信息，或者调试信息已从文件中删除，`.eh_frame` 部分也位于可执行文件中。 调用帧信息对于 C++ 中的 `throw-catch` 等语言结构的操作至关重要。

CFI 的每个功能都有一个帧描述条目（FDE）。作为其步骤之一，回溯生成过程为当前正在检查的激活帧找到适当的 FDE。将 FDE 视为一张表，每一行代表一个或多个指令，并具有以下列：

- 规范帧地址（CFA），帧指针指向的位置
- 返回地址
- 有关其他寄存器的信息

FDE 的编码旨在最大限度地减少所需的空间量。FDE 描述了行之间的变化，而不是完全指定每一行。为了进一步压缩数据，多个 FDE 共有的起始信息被分解出来并放置在通用信息条目（CIE）中。 这使得 FDE 更加紧凑，但也需要更多的工作来计算实际的 CFA 并找到返回地址位置。该工具必须从未初始化状态启动。它逐步遍历 CIE 中的条目以获取函数条目的初始状态，然后从 FDE 的第一个条目开始继续处理 FDE，并处理操作，直到到达覆盖当前正在分析的指令指针的行。

### 调用帧信息使用实例

从一个简单的示例开始，其中包含将华氏温度转换为摄氏度的函数。 内联函数在 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
```

`.eh_frame` 部分展示如下:

```
$ 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
```

本示例中，不必担心增强或增强数据条目。由于 x86_64 处理器具有 1 到 15 字节大小的可变长度指令，因此 “代码对齐因子” 设置为 1。在只有 32 位（4 字节指令）的处理器上，“代码对齐因子” 设置为 4，并且允许对一行状态信息适用的字节数进行更紧凑的编码。类似地，还有 “数据对齐因子” 来使 CFA 所在位置的调整更加紧凑。在 x86_64 上，堆栈槽的大小为 8 个字节。

虚拟表中保存返回地址的列是 16。这在 CIE 尾部的指令中使用。 有四个 `DW_CFA` 指令。第一条指令 `DW_CFA_def_cfa` 描述了如果代码具有帧指针，如何计算帧指针将指向的规范帧地址（CFA）。 在这种情况下，CFA 是根据 `r7 (rsp)` 和 `CFA=rsp+8` 计算的。

第二条指令 `DW_CFA_offset` 定义从哪里获取返回地址 `CFA-8` 。在这种情况下，返回地址当前由堆栈指针 `(rsp+8)-8` 指向。CFA 从堆栈返回地址的正上方开始。

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
```

在执行函数中的第一条指令之前，CIE 描述调用帧状态。然而，当处理器执行函数中的指令时，细节将会改变。 首先，指令 `DW_CFA_advance_loc` 和 `DW_CFA_def_cfa_offset` 与 `main` 中 `401060` 处的第一条指令匹配。 这会将堆栈指针向下调整 `0x18`（24 个字节）。 CFA 没有改变位置，但堆栈指针改变了，因此 CFA 在 `401064` 处的正确计算是 `rsp+32`。 这就是这段代码中序言指令的范围。 以下是 `main` 中的前几条指令：

```
0000000000401060 <main>:
  401060:    48 83 ec 18      sub        $0x18,%rsp
  401064:    bf 1b 20 40 00   mov        $0x40201b,%edi
```

`DW_CFA_advance_loc` 使当前行应用于函数中接下来的 50 个字节的代码，直到 `401096`。CFA 位于 `rsp+32`，直到 `401092` 处的堆栈调整指令完成执行。`DW_CFA_def_cfa_offset` 将 CFA 的计算更新为与函数入口相同。这是预期之中的，因为 `401096` 处的下一条指令是返回指令 `ret`，并将返回值从堆栈中弹出。

```
  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`，`DW_CFA_offset` 表示 `%rbx` 中的初始值现在位于 `CFA-16`（堆栈顶部）。

查看这个 `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`。

### GDB 使用调用帧信息

有了 CFI 信息，[GNU 调试器（GDB）][3] 和其他工具就可以生成准确的回溯。如果没有 CFI 信息，GDB 将很难找到返回地址。如果在 `f2c.c` 的第 7 行设置断点，可以看到 GDB 使用此信息。GDB在 `f2c` 函数中的 `pop %rbx` 完成且返回值不在栈顶之前放置了断点。

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]。

*（题图：MJ/4004d7c7-8407-40bd-8aa8-92404601dba0）*

--------------------------------------------------------------------------------

via: https://opensource.com/article/23/3/gdb-debugger-call-frame-active-function-calls

作者：[Will Cohen][a]
选题：[lkxed][b]
译者：[jrglinux](https://github.com/jrglinux)
校对：[wxy](https://github.com/wxy)

本文由 [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
[0]: https://img.linux.net.cn/data/attachment/album/202307/26/062542j0picgf1fs6nd8qn.jpg