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

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

当使用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 

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

但是对于C++程序,他们使用eh_framegcc_exception_table部分来管理exception,那么为什么编译器将eh_frameeh_frame_hdr部分放在从C程序编译的ELF呢?

首先,最初的原因主要是政治性的 – 添加基于DWARF的展开( .eh_frame )的人希望它是一个始终存在的function,因此它可以用于实现除C ++exception之外的所有类型的东西, 包含:

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

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