Perché il programma C compilato da GCC ha bisogno della sezione .eh_frame?

Il test è su Linux x86 a 32 bit con gcc 4.6.3

Quando si usa gcc per compilare un programma in C e usare readelf per controllare le informazioni sulla sezione, posso vedere le sezioni .eh_frame_hdr e .eh_frame_hdr all’interno.

Ad esempio, ecco le informazioni sulla sezione del programma binario 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 

A mio avviso, queste due sezioni sono utilizzate per la gestione delle eccezioni, producono tabelle che descrivono come scaricare lo stack.

Ma è per il programma C++ , usano le sezioni eh_frame e gcc_exception_table per gestire le eccezioni, quindi perché il compilatore inserisce le sezioni eh_frame ed eh_frame_hdr all’interno di ELF compilato dal programma C ?

Prima di tutto, la ragione originale per questo era in gran parte politica – le persone che hanno aggiunto lo sbobinamento basato su .eh_frame ( .eh_frame ) volevano che fosse una funzione sempre presente in modo che potesse essere utilizzata per implementare tutti i tipi di cose diverse dalle eccezioni C ++ , Compreso:

  • backtrace()
  • __attribute__((__cleanup__(f)))
  • __builtin_return_address(n) , per n>0
  • pthread_cleanup_push , implementato in termini di __attribute__((__cleanup__(f)))

Tuttavia, se non hai bisogno di queste cose, .eh_frame è qualcosa come un aumento del 15-30% delle dimensioni di .text senza alcun beneficio. Puoi disabilitare la generazione di .eh_frame con .eh_frame -fno-asynchronous-unwind-tables per le singole unità di traduzione, e questo per lo più elimina il costo delle dimensioni, sebbene ne crtbegin.o ancora alcune provenienti da crtbegin.o , ecc. Non puoi spogliarle con il comando strip più tardi; poiché .eh_frame è una sezione che risiede nella parte caricata del programma (questo è l’intero punto), la sua rimozione modifica il file binario in modo da interromperlo in fase di runtime. Vedi https://sourceware.org/bugzilla/show_bug.cgi?id=14037 per un esempio di come le cose possono rompersi.

Si noti che le tabelle DWARF vengono utilizzate anche per il debug, ma a tale scopo non è necessario che siano nella parte caricabile del programma. L’utilizzo di -fno-asynchronous-unwind-tables non interromperà il debug, poiché finchè -g viene passato anche al compilatore, le tabelle vengono ancora generate; vengono semplicemente archiviati in una sezione separata, non caricabile e .debug_frame del binario, .debug_frame .