con - ¿Por qué el programa C compilado por GCC necesita la sección.eh_frame?

gcc linux

Question

La prueba es en Linux x86 de 32 bits con gcc 4.6.3

Al usar gcc para compilar un programa en C y usar readelf para verificar la información de la sección, puedo ver las secciones .eh_frame_hdr y .eh_frame_hdr dentro.

Por ejemplo, aquí está la información de la sección del programa 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

En mi opinión, estas dos secciones se usan para manejar excepciones, producen tablas que describen cómo desenrollar la pila.

Pero es para el programa C++ , usan las secciones eh_frame y gcc_exception_table para administrar las excepciones, entonces ¿por qué el compilador coloca las secciones eh_frame y eh_frame_hdr dentro del ELF compilado del programa C ?

Answer 1

En primer lugar, la razón original de esto fue en gran medida política: las personas que agregaron el desenrollado basado en DWARF ( .eh_frame ) querían que fuera una característica que siempre estuviera ahí, por lo que podría usarse para implementar todo tipo de cosas además de solo excepciones de C ++ , incluyendo:

• backtrace()
• __attribute__((__cleanup__(f)))
• __builtin_return_address(n) , para n>0
• pthread_cleanup_push , implementado en términos de __attribute__((__cleanup__(f)))
• ...

Sin embargo, si no necesita ninguna de estas cosas, .eh_frame es algo así como un aumento del 15-30% al tamaño de .text sin ningún beneficio. Puede deshabilitar la generación de .eh_frame con -fno-asynchronous-unwind-tables para unidades de traducción individuales, y esto elimina principalmente el costo de tamaño, aunque todavía le quedan algunos provenientes de crtbegin.o , etc. No puede eliminarlos con el comando strip más tarde; dado que .eh_frame es una sección que vive en la parte cargada del programa (este es el punto completo), su eliminación modifica el binario de manera que lo rompe en tiempo de ejecución. Consulte https://sourceware.org/bugzilla/show_bug.cgi?id=14037 para ver un ejemplo de cómo se pueden romper las cosas.

Tenga en cuenta que las tablas DWARF también se usan para la depuración, pero para este propósito no necesitan estar en la parte cargable del programa. El uso de -fno-asynchronous-unwind-tables no interrumpirá la depuración, porque mientras -g también se pasa al compilador, las tablas aún se generan; simplemente se almacenan en una sección separada, no cargable y separable del binario, .debug_frame .