mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-23 21:20:42 +08:00
Xingyu Wang
parent
702e50fa65
commit
3582f71b01
@ -3,22 +3,26 @@
|
||||
[#]: author: "Will Cohen https://opensource.com/users/wcohen"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: "jrglinux"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
[#]: reviewer: "wxy"
|
||||
[#]: publisher: "wxy"
|
||||
[#]: url: "https://linux.cn/article-16033-1.html"
|
||||
|
||||
GDB以及其他调试器如何通过调用帧信息来确定函数调用关系
|
||||
GDB 调试器如何通过调用帧信息来确定函数调用关系
|
||||
======
|
||||
|
||||
在我的[上一篇文章][1]中，我展示了如何使用 debuginfo 在当前指令指针 (IP) 和包含它的函数或行之间进行映射。 该信息对于显示 CPU 当前正在执行的代码很有帮助。 不过，如果能显示更多的有关当前函数调用栈及其正在执行语句的上下文对我们定位问题来说也是十分有助的。
|
||||
![][0]
|
||||
|
||||
例如，将空指针作为参数传递到函数中而导致非法内存访问的问题， 只需查看当前执行函数行即可发现该错误是由尝试通过空指针进行访问而触发的。 但是，若真正知道导致空指针访问的函数调用的完整上下文，便确定该空指针最初是如何传递到该函数中的。 此上下文信息由回溯提供，并允许您确定哪些函数可能对空指针参数负责。
|
||||
> 从调试器中获取函数调用关系。
|
||||
|
||||
在我的 [上一篇文章][1] 中，我展示了如何使用 `debuginfo` 在当前指令指针（IP）和包含它的函数或行之间进行映射。该信息对于显示 CPU 当前正在执行的代码很有帮助。不过，如果能显示更多的有关当前函数调用栈及其正在执行语句的上下文对我们定位问题来说也是十分有助的。
|
||||
|
||||
例如，将空指针作为参数传递到函数中而导致非法内存访问的问题，只需查看当前执行函数行，即可发现该错误是由尝试通过空指针进行访问而触发的。但是，你真正想知道的是导致空指针访问的函数调用的完整上下文，以便确定该空指针最初是如何传递到该函数中的。此上下文信息由回溯提供，可以让你确定哪些函数可能对空指针参数负责。
|
||||
|
||||
有一点是肯定的：确定当前活动的函数调用栈不是一项简单的操作。
|
||||
|
||||
### 函数激活记录
|
||||
|
||||
现代编程语言具有局部变量，并允许函数可以调用自身的递归。 此外，并发程序具有多个线程，这些线程可能同时运行相同的函数。 在这些情况下，局部变量不能存储在全局位置。 对于函数的每次调用，局部变量的位置必须是唯一的。 它的工作原理如下：
|
||||
现代编程语言具有局部变量，并允许函数可以调用自身的递归。此外，并发程序具有多个线程，这些线程可能同时运行相同的函数。在这些情况下，局部变量不能存储在全局位置。对于函数的每次调用，局部变量的位置必须是唯一的。它的工作原理如下：
|
||||
|
||||
- 每次调用函数时，编译器都会生成函数激活记录，以将局部变量存储在唯一位置。
|
||||
- 为了提高效率，处理器堆栈用于存储函数激活记录。
|
||||
@ -26,29 +30,29 @@ GDB以及其他调试器如何通过调用帧信息来确定函数调用关系
|
||||
- 如果该函数调用另一个函数，则新的函数激活记录将放置在现有函数激活记录之上。
|
||||
- 每次函数返回时，其函数激活记录都会从堆栈中删除。
|
||||
|
||||
函数激活记录的创建是由函数中称为序言的代码创建的。 函数激活记录的删除由函数尾声处理。 函数体可以利用堆栈上为其预留的内存来存储临时值和局部变量。
|
||||
函数激活记录的创建是由函数中称为“<ruby>序言<rt>prologue</rt></ruby>”的代码创建的。函数激活记录的删除由函数“<ruby>尾声<rt>epilogue</rt></ruby>”处理。函数体可以利用堆栈上为其预留的内存来存储临时值和局部变量。
|
||||
|
||||
函数激活记录的大小可以是可变的。 对于某些函数，不需要空间来存储局部变量。 理想情况下，函数激活记录只需要存储调用_this_函数的函数的返回地址。 对于其他函数，除了返回地址之外，可能还需要大量空间来存储函数的本地数据结构。 帧大小的可变导致编译器使用帧指针来跟踪函数激活帧的开始。函数序言代码具有在为当前函数创建新帧指针之前存储旧帧指针的额外任务，并且函数尾声必须恢复旧帧指针值。
|
||||
函数激活记录的大小可以是可变的。对于某些函数，不需要空间来存储局部变量。理想情况下，函数激活记录只需要存储调用 _该_ 函数的函数的返回地址。对于其他函数，除了返回地址之外，可能还需要大量空间来存储函数的本地数据结构。帧大小的可变导致编译器使用帧指针来跟踪函数激活帧的开始。函数序言代码具有在为当前函数创建新帧指针之前存储旧帧指针的额外任务，并且函数尾声必须恢复旧帧指针值。
|
||||
|
||||
函数激活记录的布局方式、调用函数的返回地址和旧帧指针是相对于当前帧指针的恒定偏移量。 通过旧的帧指针，可以定位堆栈上下一个函数的激活帧。 重复此过程，直到检查完所有功能激活记录为止。
|
||||
函数激活记录的布局方式、调用函数的返回地址和旧帧指针是相对于当前帧指针的恒定偏移量。通过旧的帧指针，可以定位堆栈上下一个函数的激活帧。重复此过程，直到检查完所有函数激活记录为止。
|
||||
|
||||
### 优化复杂性
|
||||
|
||||
在代码中使用显式帧指针有几个缺点。 在某些处理器上，可用的寄存器相对较少。 具有显式帧指针会导致使用更多内存操作。 生成的代码速度较慢，因为帧指针必须位于寄存器中。 具有显式帧指针可能会限制编译器可以生成的代码，因为编译器可能不会将函数序言和结尾代码与函数体混合。
|
||||
在代码中使用显式帧指针有几个缺点。在某些处理器上，可用的寄存器相对较少。具有显式帧指针会导致使用更多内存操作。生成的代码速度较慢，因为帧指针必须位于寄存器中。具有显式帧指针可能会限制编译器可以生成的代码，因为编译器可能不会将函数序言和尾声代码与函数体混合。
|
||||
|
||||
编译器的目标是尽可能生成快速代码，因此编译器通常会从生成的代码中省略帧指针。 正如 [Phoronix 的基准测试][2] 所示，保留帧指针会显着降低性能。 不过省略帧指针也有缺点，查找前一个调用函数的激活帧和返回地址不再是相对于帧指针的简单偏移。
|
||||
编译器的目标是尽可能生成快速代码，因此编译器通常会从生成的代码中省略帧指针。正如 [Phoronix 的基准测试][2] 所示，保留帧指针会显着降低性能。不过省略帧指针也有缺点，查找前一个调用函数的激活帧和返回地址不再是相对于帧指针的简单偏移。
|
||||
|
||||
### 调用帧信息
|
||||
|
||||
为了帮助生成函数回溯，编译器包含 DWARF 调用帧信息 (CFI) 来重建帧指针并查找返回地址。 此补充信息存储在执行的 `.eh_frame` 部分中。 与传统的函数和行位置信息的 debuginfo 不同，即使生成的可执行文件没有调试信息，或者调试信息已从文件中删除，`.eh_frame` 部分也位于可执行文件中。 调用帧信息对于 C++ 中的 **throw-catch** 等语言结构的操作至关重要。
|
||||
为了帮助生成函数回溯，编译器包含 DWARF 调用帧信息（CFI）来重建帧指针并查找返回地址。此补充信息存储在执行的 `.eh_frame` 部分中。与传统的函数和行位置信息的 `debuginfo` 不同，即使生成的可执行文件没有调试信息，或者调试信息已从文件中删除，`.eh_frame` 部分也位于可执行文件中。 调用帧信息对于 C++ 中的 `throw-catch` 等语言结构的操作至关重要。
|
||||
|
||||
CFI 的每个功能都有一个帧描述条目 (FDE)。 作为其步骤之一，回溯生成过程为当前正在检查的激活帧找到适当的 FDE。 将 FDE 视为一张表，每一行代表一个或多个指令，并具有以下列：
|
||||
CFI 的每个功能都有一个帧描述条目（FDE）。作为其步骤之一，回溯生成过程为当前正在检查的激活帧找到适当的 FDE。将 FDE 视为一张表，每一行代表一个或多个指令，并具有以下列：
|
||||
|
||||
- 规范帧地址（CFA），帧指针指向的位置
|
||||
- 返回地址
|
||||
- 有关其他寄存器的信息
|
||||
|
||||
FDE 的编码旨在最大限度地减少所需的空间量。 FDE 描述了行之间的变化，而不是完全指定每一行。 为了进一步压缩数据，多个 FDE 共有的起始信息被分解出来并放置在通用信息条目 (CIE) 中。 这使得 FDE 更加紧凑，但也需要更多的工作来计算实际的 CFA 并找到返回地址位置。 该工具必须从未初始化状态启动。 它逐步遍历 CIE 中的条目以获取函数条目的初始状态，然后从 FDE 的第一个条目开始继续处理 FDE，并处理操作，直到到达覆盖当前正在分析的指令指针的行。
|
||||
FDE 的编码旨在最大限度地减少所需的空间量。FDE 描述了行之间的变化，而不是完全指定每一行。为了进一步压缩数据，多个 FDE 共有的起始信息被分解出来并放置在通用信息条目（CIE）中。 这使得 FDE 更加紧凑，但也需要更多的工作来计算实际的 CFA 并找到返回地址位置。该工具必须从未初始化状态启动。它逐步遍历 CIE 中的条目以获取函数条目的初始状态，然后从 FDE 的第一个条目开始继续处理 FDE，并处理操作，直到到达覆盖当前正在分析的指令指针的行。
|
||||
|
||||
### 调用帧信息使用实例
|
||||
|
||||
@ -81,7 +85,7 @@ int main (int argc, char *argv[])
|
||||
$ gcc -O2 -g -o f2c f2c.c
|
||||
```
|
||||
|
||||
`.eh_frame` 部分展示如下:
|
||||
`.eh_frame` 部分展示如下:
|
||||
|
||||
```
|
||||
$ eu-readelf -S f2c |grep eh_frame
|
||||
@ -124,11 +128,11 @@ $ objdump -d f2c > f2c.dis
|
||||
DW_CFA_nop
|
||||
```
|
||||
|
||||
本示例中，不必担心增强或增强数据条目。 由于 x86_64 处理器具有 1 到 15 字节大小的可变长度指令，因此 "代码对齐因子" 设置为 1。在只有 32 位（4 字节指令）的处理器上，"代码对齐因子" 设置为 4，并且允许对一行状态信息适用的字节数进行更紧凑的编码。 类似地，还有 "数据对齐因子" 来使 CFA 所在位置的调整更加紧凑。 在 x86_64 上，堆栈槽的大小为 8 个字节。
|
||||
本示例中，不必担心增强或增强数据条目。由于 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` 计算的。
|
||||
虚拟表中保存返回地址的列是 16。这在 CIE 尾部的指令中使用。 有四个 `DW_CFA` 指令。第一条指令 `DW_CFA_def_cfa` 描述了如果代码具有帧指针，如何计算帧指针将指向的规范帧地址（CFA）。 在这种情况下，CFA 是根据 `r7 (rsp)` 和 `CFA=rsp+8` 计算的。
|
||||
|
||||
第二条指令 `DW_CFA_offset` 定义从哪里获取返回地址 `CFA-8` 。 在这种情况下，返回地址当前由堆栈指针 `(rsp+8)-8` 指向。 CFA 从堆栈返回地址的正上方开始。
|
||||
第二条指令 `DW_CFA_offset` 定义从哪里获取返回地址 `CFA-8` 。在这种情况下，返回地址当前由堆栈指针 `(rsp+8)-8` 指向。CFA 从堆栈返回地址的正上方开始。
|
||||
|
||||
CIE 末尾的 `DW_CFA_nop` 进行填充以保持 DWARF 信息的对齐。 FDE 还可以在末尾添加填充以进行对齐。
|
||||
|
||||
@ -143,7 +147,7 @@ CIE 末尾的 `DW_CFA_nop` 进行填充以保持 DWARF 信息的对齐。 FDE
|
||||
DW_CFA_nop
|
||||
```
|
||||
|
||||
在执行函数中的第一条指令之前，CIE 描述调用帧状态。 然而，当处理器执行函数中的指令时，细节将会改变。 首先，指令 `DW_CFA_advance_loc` 和 `DW_CFA_def_cfa_offset` 与 `main` 中 `401060` 处的第一条指令匹配。 这会将堆栈指针向下调整 `0x18`（24 个字节）。 CFA 没有改变位置，但堆栈指针改变了，因此 CFA 在 `401064` 处的正确计算是 `rsp+32`。 这就是这段代码中序言指令的范围。 以下是 `main` 中的前几条指令：
|
||||
在执行函数中的第一条指令之前，CIE 描述调用帧状态。然而，当处理器执行函数中的指令时，细节将会改变。 首先，指令 `DW_CFA_advance_loc` 和 `DW_CFA_def_cfa_offset` 与 `main` 中 `401060` 处的第一条指令匹配。 这会将堆栈指针向下调整 `0x18`（24 个字节）。 CFA 没有改变位置，但堆栈指针改变了，因此 CFA 在 `401064` 处的正确计算是 `rsp+32`。 这就是这段代码中序言指令的范围。 以下是 `main` 中的前几条指令：
|
||||
|
||||
```
|
||||
0000000000401060 <main>:
|
||||
@ -151,7 +155,7 @@ CIE 末尾的 `DW_CFA_nop` 进行填充以保持 DWARF 信息的对齐。 FDE
|
||||
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`，并将返回值从堆栈中弹出。
|
||||
`DW_CFA_advance_loc` 使当前行应用于函数中接下来的 50 个字节的代码，直到 `401096`。CFA 位于 `rsp+32`，直到 `401092` 处的堆栈调整指令完成执行。`DW_CFA_def_cfa_offset` 将 CFA 的计算更新为与函数入口相同。这是预期之中的，因为 `401096` 处的下一条指令是返回指令 `ret`，并将返回值从堆栈中弹出。
|
||||
|
||||
```
|
||||
401090: 31 c0 xor %eax,%eax
|
||||
@ -196,11 +200,11 @@ CIE 末尾的 `DW_CFA_nop` 进行填充以保持 DWARF 信息的对齐。 FDE
|
||||
|
||||
在 `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`。
|
||||
查看这个 `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使用调用帧信息
|
||||
### GDB 使用调用帧信息
|
||||
|
||||
有了 CFI 信息，[GNU 调试器 (GDB)][3] 和其他工具就可以生成准确的回溯。 如果没有 CFI 信息，GDB 将很难找到返回地址。 如果在 `f2c.c` 的第 7 行设置断点，可以看到 GDB 使用此信息。 GDB在 `f2c` 函数中的 `pop %rbx` 完成且返回值不在栈顶之前放置了断点。
|
||||
有了 CFI 信息，[GNU 调试器（GDB）][3] 和其他工具就可以生成准确的回溯。如果没有 CFI 信息，GDB 将很难找到返回地址。如果在 `f2c.c` 的第 7 行设置断点，可以看到 GDB 使用此信息。GDB在 `f2c` 函数中的 `pop %rbx` 完成且返回值不在栈顶之前放置了断点。
|
||||
|
||||
GDB 能够展开堆栈，并且作为额外收获还能够获取当前保存在堆栈上的参数 `f`：
|
||||
|
||||
@ -228,6 +232,8 @@ Breakpoint 1, f2c (f=98) at f2c.c:8
|
||||
|
||||
DWARF 调用帧信息为编译器提供了一种灵活的方式来包含用于准确展开堆栈的信息。这使得可以确定当前活动的函数调用。我在本文中提供了简要介绍，但有关 DWARF 如何实现此机制的更多详细信息，请参阅 [DWARF 规范][4]。
|
||||
|
||||
*（题图：MJ/4004d7c7-8407-40bd-8aa8-92404601dba0）*
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/23/3/gdb-debugger-call-frame-active-function-calls
|
||||
@ -235,7 +241,7 @@ via: https://opensource.com/article/23/3/gdb-debugger-call-frame-active-function
|
||||
作者：[Will Cohen][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[jrglinux](https://github.com/jrglinux)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -245,3 +251,4 @@ via: https://opensource.com/article/23/3/gdb-debugger-call-frame-active-function
|
||||
[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
|
||||
Loading…
Reference in New Issue
Block a user