为什么 GCC 编译的 C 程序需要 .eh_frame 部分? [英] Why GCC compiled C program needs .eh_frame section?

问题描述

测试在 32 位 x86 Linux 上使用 gcc 4.6.3

Test is on 32 bit x86 Linux with gcc 4.6.3

当使用gcc编译C程序并使用readelf查看section信息时，我可以看到里面的 .eh_frame 部分和 .eh_frame_hdr 部分.

When using gcc to compile a C program and using readelf to check the section info, I can see the .eh_frame section and .eh_frame_hdr sections inside.

例如，这里是二进制程序Perlbench的section信息.

For example, here is the section info of binary program Perlbench.

readelf -S perlbench

There are 28 section headers, starting at offset 0x102e48:

Section Headers:
[Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
[ 0]                   NULL            00000000 000000 000000 00      0   0  0
[ 1] .interp           PROGBITS        08048154 000154 000013 00   A  0   0  1
[ 2] .note.ABI-tag     NOTE            08048168 000168 000020 00   A  0   0  4
[ 3] .note.gnu.build-i NOTE            08048188 000188 000024 00   A  0   0  4
[ 4] .gnu.hash         GNU_HASH        080481ac 0001ac 000044 04   A  5   0  4
[ 5] .dynsym           DYNSYM          080481f0 0001f0 0007b0 10   A  6   1  4
[ 6] .dynstr           STRTAB          080489a0 0009a0 0003d6 00   A  0   0  1
[ 7] .gnu.version      VERSYM          08048d76 000d76 0000f6 02   A  5   0  2
[ 8] .gnu.version_r    VERNEED         08048e6c 000e6c 0000a0 00   A  6   2  4
[ 9] .rel.dyn          REL             08048f0c 000f0c 000028 08   A  5   0  4
[10] .rel.plt          REL             08048f34 000f34 000388 08   A  5  12  4
[11] .init             PROGBITS        080492bc 0012bc 00002e 00  AX  0   0  4
[12] .plt              PROGBITS        080492f0 0012f0 000720 04  AX  0   0 16
[13] .text             PROGBITS        08049a10 001a10 0cf86c 00  AX  0   0 16
[14] .fini             PROGBITS        0811927c 0d127c 00001a 00  AX  0   0  4
[15] .rodata           PROGBITS        081192a0 0d12a0 017960 00   A  0   0 32
[16] .eh_frame_hdr     PROGBITS        08130c00 0e8c00 003604 00   A  0   0  4
[17] .eh_frame         PROGBITS        08134204 0ec204 01377c 00   A  0   0  4
[18] .ctors            PROGBITS        08148f0c 0fff0c 000008 00  WA  0   0  4
[19] .dtors            PROGBITS        08148f14 0fff14 000008 00  WA  0   0  4
[20] .jcr              PROGBITS        08148f1c 0fff1c 000004 00  WA  0   0  4
[21] .dynamic          DYNAMIC         08148f20 0fff20 0000d0 08  WA  6   0  4
[22] .got              PROGBITS        08148ff0 0ffff0 000004 04  WA  0   0  4
[23] .got.plt          PROGBITS        08148ff4 0ffff4 0001d0 04  WA  0   0  4
[24] .data             PROGBITS        081491e0 1001e0 002b50 00  WA  0   0 32
[25] .bss              NOBITS          0814bd40 102d30 002b60 00  WA  0   0 32
[26] .comment          PROGBITS        00000000 102d30 00002a 01  MS  0   0  1
[27] .shstrtab         STRTAB          00000000 102d5a 0000ec 00      0   0  1

在我的理解中，这两个部分用于处理异常，它生成描述如何展开堆栈的表.

In my understanding, these two sections are used for handling exceptions, it produce tables that describe how to unwind the stack.

但是对于C++程序来说，他们使用eh_frame和gcc_exception_table段来管理异常，那为什么编译器把ELF 中的 eh_frame 和 eh_frame_hdr 部分是从 C 程序编译的?

But it is for C++ program, they use eh_frame and gcc_exception_table sections to manage exceptions, then why does compiler put the eh_frame and eh_frame_hdr sections inside ELF compiled from C program?

推荐答案

首先，造成这种情况的最初原因主要是政治性的 - 添加基于 DWARF 的展开 (.eh_frame) 的人想要它是一个始终存在的功能，因此它可以用于实现除 C++ 异常之外的所有类型的东西，包括:

First of all, the original reason for this was largely political - the people who added DWARF-based unwinding (.eh_frame) wanted it to be a feature that's always there so it could be used for implementing all kinds of stuff other than just C++ exceptions, including:

• backtrace()
• __attribute__((__cleanup__(f)))
• __builtin_return_address(n)，对于n>0
• pthread_cleanup_push，根据__attribute__((__cleanup__(f)))
实现
• ...

但是，如果您不需要任何这些东西，.eh_frame 就像是将 .text 大小增加 15-30% 而没有任何好处.您可以使用 -fno-asynchronous-unwind-tables 为单个翻译单元禁用 .eh_frame 的生成，这主要消除了大小成本，尽管您还有一些来自 crtbegin.o 等.你不能稍后用 strip 命令剥离它们；由于 .eh_frame 是位于程序加载部分的一个部分(这是重点)，剥离它会以在运行时破坏它的方式修改二进制文件.请参阅 https://sourceware.org/bugzilla/show_bug.cgi?id=14037 的示例事情怎么可能会破裂.

However if you don't need any of these things, .eh_frame is something like a 15-30% increase to .text size with no benefit. You can disable generation of .eh_frame with -fno-asynchronous-unwind-tables for individual translation units, and this mostly eliminates the size cost, although you still have a few left over coming from crtbegin.o, etc. You cannot strip them with the strip command later; since .eh_frame is a section that lives in the loaded part of the program (this is the whole point), stripping it modifies the binary in ways that break it at runtime. See https://sourceware.org/bugzilla/show_bug.cgi?id=14037 for an example of how things can break.

请注意，DWARF 表也用于调试，但为此目的，它们不需要位于程序的可加载部分.使用 -fno-asynchronous-unwind-tables 不会破坏调试，因为只要 -g 也传递给编译器，表仍然会生成；它们只是存储在二进制文件的一个单独的、不可加载的、可剥离的部分中，.debug_frame.

Note that DWARF tables are also used for debugging, but for this purpose they do not need to be in the loadable part of the program. Using -fno-asynchronous-unwind-tables will not break debugging, because as long as -g is also passed to the compiler, the tables still get generated; they just get stored in a separate, non-loadable, strippable section of the binary, .debug_frame.

这篇关于为什么 GCC 编译的 C 程序需要 .eh_frame 部分?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！