Question

使用gcc 4.6.3

在32位x86 Linux上进行测试

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

例如，这是二进制程序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

根据我的理解，这两个部分用于处理异常，它会生成描述如何展开堆栈的表。

但它适用于C++程序，他们使用eh_frame和gcc_exception_table部分来管理异常，那么为什么编译器会放置eh_frame和eh_frame_hdr部分从ELF程序编译的C内部？

Answer 1

首先，最初的原因主要是政治性的 - 添加基于DWARF的展开（.eh_frame）的人希望它成为一个始终存在的功能，因此它可以用于实现各种除了C ++异常之外的东西，包括：

backtrace()
__attribute__((__cleanup__(f)))
__builtin_return_address(n)，n>0
pthread_cleanup_push，以__attribute__((__cleanup__(f)))
...

但是，如果您不需要任何这些内容，.eh_frame就会比.text增加15-30％而没有任何好处。您可以针对单个翻译单元停用.eh_frame生成-fno-asynchronous-unwind-tables，这大多可以消除尺寸成本，但仍有一些遗留来自crtbegin.o等等。您不能以后用strip命令剥离它们;因为.eh_frame是一个存在于程序加载部分的部分（这是整点），所以剥离它会以在运行时中断它的方式修改二进制文件。有关事情如何破裂的示例，请参阅https://sourceware.org/bugzilla/show_bug.cgi?id=14037。

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

为什么GCC编译C程序需要.eh_frame部分？

1 个答案: