GCCでコンパイルされたCプログラムに.eh_frameセクションが必要なのはなぜですか?
テストは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
私の理解では、これらの2つのセクションは例外の処理に使用され、スタックの巻き戻し方法を説明するテーブルを生成します。
しかし、それはC++
プログラム、彼らはeh_frame
およびgcc_exception_table
セクションで例外を管理し、コンパイラーがeh_frame
およびeh_frame_hdr
ELF
プログラムからコンパイルされたC
内のセクション?
まず第一に、これの元々の理由は主に政治的なものでした-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
_などからの残りがいくつか残っていますが、ほとんどの場合、サイズのコストがなくなります。 cannot後でstrip
コマンドで削除します。 _.eh_frame
_はプログラムのロードされた部分(これが全体のポイントです)にあるセクションであるため、それを削除すると、実行時に壊れるような方法でバイナリが変更されます。物事がどのように壊れるかの例については、 https://sourceware.org/bugzilla/show_bug.cgi?id=14037 を参照してください。
DWARFテーブルはデバッグにも使用されますが、この目的のために、プログラムのロード可能な部分にある必要はありません。 _-fno-asynchronous-unwind-tables
_を使用しても、デバッグが中断されることはありません。これは、_-g
_もコンパイラに渡される限り、テーブルが生成されるためです。それらは、バイナリの別個のロード不可能なストリップ可能なセクション_.debug_frame
_に格納されます。