Почему версия компилятора появляется в моем исполняемом элементе ELF?
Недавно я скомпилировал простую программу hello world C под Debian Linux, используя gcc:
gcc -mtune=native -march=native -m32 -s -Wunused -O2 -o hello hello.c
Размер файла составил 2980 байт. Я открыл его в шестнадцатеричном редакторе и увидел следующие строки:
GCC: (Debian 4.4.5-8) 4.4.5 GCC: (Debian 4.4.5-10) 4.4.5 .shstrtab .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .text .fini .rodata .eh_frame .ctors .dtors .jcr .dynamic .got .got.plt data.data .bss .comment
Они действительно нужны? Невозможно уменьшить размер исполняемого файла?
Ответы
Ответ 1
Это в разделе комментариев в бинарнике ELF. Вы можете удалить его:
$ gcc -m32 -O2 -s -o t t.c
$ ls -l t
-rwxr-xr-x 1 me users 5488 Jun 7 11:58 t
$ readelf -p .comment t
String dump of section '.comment':
[ 0] GCC: (Gentoo 4.5.1-r1 p1.4, pie-0.4.5) 4.5.1
[ 2d] GCC: (Gentoo 4.5.2 p1.1, pie-0.4.5) 4.5.2
$ strip -R .comment t
$ readelf -p .comment t
readelf: Warning: Section '.comment' was not dumped because it does not exist!
$ ls -l t
-rwxr-xr-x 1 me users 5352 Jun 7 11:58 t
Прибыль крошечная, хотя и не уверена, что это того стоит.
Ответ 2
используйте -Qn, чтобы этого избежать.
aa$ touch hello.c
aa$ gcc -c hello.c
aa$ objdump -s hello.o
hello.o: file format elf32-i386
Contents of section .comment:
0000 00474343 3a202844 65626961 6e20342e .GCC: (Debian 4.
0010 372e322d 35292034 2e372e32 00 7.2-5) 4.7.2.
aa$ gcc -Qn -c hello.c
aa$ objdump -s hello.o
hello.o: file format elf32-i386
aa$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.7/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
aa$
Ответ 3
Это раздел комментариев, который не загружен в память (и обратите внимание, что файлы ELF обычно используют отступы, чтобы их сопоставление с памятью сохраняло правильное выравнивание). Если вы хотите избавиться от таких ненужных разделов, просмотрите различные опции objcopy и узнайте:
objcopy --remove-section .comment a.o b.o
Ответ 4
У меня была такая же проблема сама, но с использованием MinGW GCC-реализации - удаление исполняемого файла и передача параметра -Qn ничего не делали, и я не мог удалить раздел ".comment", поскольку его не было.
Чтобы остановить компилятор, включая эту информацию, независимо от того, какие разделы находятся в вашем исполняемом файле, вы можете передать параметр -fno-ident компилятору и компоновщику:
Без параметра (строки -a [имя_файла]):
!This program cannot be run in DOS mode.
.text
0`.rdata
[email protected]
GCC: (tdm64-2) 4.8.1
С параметром:
!This program cannot be run in DOS mode.
.text
0`.idata
Ответ 5
Похоже, вы сможете "просто" снять это, если вы этого не хотите; См. Эту страницу для приятного прогона.
http://timelessname.com/elfbin/
Обратите внимание, что на странице (конечно) также используется сборка, которую вы, возможно, не захотите делать, но общий смысл применяется
Ответ 6
Вы можете сообщить загрузчику, какие разделы включать в ваш вывод с помощью компоновщика script. Вы можете видеть, какие разделы включены в файл, используя команду objdump. Как вы заметили там хороший бит "мусора" в эльфийском барахле, до тех пор, пока вы этого не пожелаете.
Обратите внимание, что размер исполняемого файла эльфа не указывает на печать стопы памяти изображения, реализованную в памяти. Большая часть "мусора" не находится в изображении памяти, и изображение может вызывать sbreak и/или mmap для получения большей памяти, в файле elf не учитывается использование стека - по сути, все ваши автоматические переменные не учитываются. Это всего лишь три примера, в которых много других.