Почему скомпилированная 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
В моем понимании, эти два раздела используются для обработки исключений, он создает таблицы, которые описывают, как разматывать стек.
Но это для C++ программа, которую они используют eh_frame а также gcc_exception_table разделы для управления исключениями, то почему компилятор ставит eh_frame а также eh_frame_hdr разделы внутри ELF составлено из C программа?
1 ответ
Прежде всего, первоначальная причина этого была в значительной степени политической - люди, которые добавили раскручивание на основе DWARF (.eh_frame) хотел, чтобы это была функция, которая всегда есть, чтобы ее можно было использовать для реализации всех видов вещей, кроме исключений C++, включая:
backtrace()__attribute__((__cleanup__(f)))__builtin_return_address(n), заn>0pthread_cleanup_push, реализованный с точки зрения__attribute__((__cleanup__(f)))- ...
Однако, если вам не нужны эти вещи, .eh_frame что-то вроде увеличения на 15-30% до .text размер без пользы. Вы можете отключить генерацию .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,