测试在 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
根据我的理解，这两个部分用于处理异常，它生成描述如何展开堆栈的表。
但它是为了C++程序，他们使用eh_frame and gcc_exception_table部分来管理异常，那么为什么编译器将eh_frame and eh_frame_hdr里面的部分ELF编译自C程序？
首先，最初的原因很大程度上是政治性的——添加基于 DWARF 的展开的人们（.eh_frame）希望它成为一个始终存在的功能，因此它可以用于实现除 C++ 异常之外的各种内容，包括：
backtrace()__attribute__((__cleanup__(f)))-
__builtin_return_address(n), for n>0
-
pthread_cleanup_push，实施方式为__attribute__((__cleanup__(f)))
- ...
但是，如果您不需要这些东西，.eh_frame大约增加 15-30%.text大小没有任何好处。您可以禁用生成.eh_frame with -fno-asynchronous-unwind-tables对于单个翻译单元，这基本上消除了大小成本，尽管您仍然有一些剩余的crtbegin.o等你cannot剥掉它们strip稍后指挥；自从.eh_frame是存在于程序的已加载部分中的一个部分（这就是重点），剥离它会以在运行时破坏它的方式修改二进制文件。看https://sourceware.org/bugzilla/show_bug.cgi?id=14037举个例子来说明事情是如何崩溃的。
请注意，DWARF 表也用于调试，但为此目的，它们不需要位于程序的可加载部分。使用-fno-asynchronous-unwind-tables不会破坏调试，因为只要-g也传递给编译器，表仍然生成；它们只是存储在二进制文件的一个单独的、不可加载的、可剥离的部分中，.debug_frame.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
