2016-03-25 3 views
1

Я построил свое приложение (c/C++) на linux и разделил его с помощью команды «strip». Я думал, что без каких-либо опций он будет удалять всю информацию об отладке из исходного двоичного файла. Я разделся, используя следующие:Отладочные секции после двоичного удаления

strip my_app -o $odir/my_app_stripped (where $odir is preconfigured location) 

Однако, когда я делаю следующее:

objdump -h my_app_stripped 

Это дает мне следующий вывод:

my_app_stripped: file format elf32-i386 
Sections: 
Idx Name   Size  VMA  LMA  File off Algn 
0 .interp  0000002c 00048154 00048154 00000154 2**0 
       CONTENTS, ALLOC, LOAD, READONLY, DATA 
1 .note.ABI-tag 00000020 00048180 00048180 00000180 2**2 
       CONTENTS, ALLOC, LOAD, READONLY, DATA 
2 .hash   00067dcc 000481a0 000481a0 000001a0 2**2 
       CONTENTS, ALLOC, LOAD, READONLY, DATA 
3 .dynsym  0011f6e0 000aff6c 000aff6c 00067f6c 2**2 
       CONTENTS, ALLOC, LOAD, READONLY, DATA 
4 .dynstr  00488e4c 001cf64c 001cf64c 0018764c 2**0 
       CONTENTS, ALLOC, LOAD, READONLY, DATA 
5 .gnu.version 00023edc 00658498 00658498 00610498 2**1 
       CONTENTS, ALLOC, LOAD, READONLY, DATA 
6 .gnu.version_r 00000290 0067c374 0067c374 00634374 2**2 
       CONTENTS, ALLOC, LOAD, READONLY, DATA 
7 .rel.dyn  00006860 0067c604 0067c604 00634604 2**2 
       CONTENTS, ALLOC, LOAD, READONLY, DATA 
8 .rel.plt  00003768 00682e64 00682e64 0063ae64 2**2 
       CONTENTS, ALLOC, LOAD, READONLY, DATA 
9 .init   00000017 006865cc 006865cc 0063e5cc 2**2 
       CONTENTS, ALLOC, LOAD, READONLY, CODE 
10 .plt   00006ee0 006865e4 006865e4 0063e5e4 2**2 
       CONTENTS, ALLOC, LOAD, READONLY, CODE 
11 .text   01120918 0068d4d0 0068d4d0 006454d0 2**4 
       CONTENTS, ALLOC, LOAD, READONLY, CODE 
12 BINK   00018d20 017addf0 017addf0 01765df0 2**4 
       CONTENTS, ALLOC, LOAD, READONLY, CODE 
13 BINK32  00001350 017c6b10 017c6b10 0177eb10 2**4 
       CONTENTS, ALLOC, LOAD, READONLY, CODE 
14 BINK16  00001008 017c7e60 017c7e60 0177fe60 2**4 
       CONTENTS, ALLOC, LOAD, READONLY, CODE 
15 BINKP8  000008fb 017c8e70 017c8e70 01780e70 2**4 
       CONTENTS, ALLOC, LOAD, READONLY, CODE 
16 BINKY16  000008e1 017c9770 017c9770 01781770 2**4 
       CONTENTS, ALLOC, LOAD, READONLY, CODE 
17 BINKY12  000001b0 017ca060 017ca060 01782060 2**4 
       CONTENTS, ALLOC, LOAD, READONLY, CODE 
18 .fini   0000001a 017ca210 017ca210 01782210 2**2 
       CONTENTS, ALLOC, LOAD, READONLY, CODE 
19 .rodata  00164204 017ca240 017ca240 01782240 2**6 
       CONTENTS, ALLOC, LOAD, READONLY, DATA 
20 .debug$S  000010f8 0192e444 0192e444 018e6444 2**0 
       CONTENTS, ALLOC, LOAD, READONLY, DATA 
21 BINKCONST  00004e40 0192f540 0192f540 018e7540 2**6 
       CONTENTS, ALLOC, LOAD, READONLY, DATA 
22 .debug$F  00000250 01934380 01934380 018ec380 2**0 
       CONTENTS, ALLOC, LOAD, READONLY, DATA 
23 .rdata  00000080 019345d0 019345d0 018ec5d0 2**4 
       CONTENTS, ALLOC, LOAD, READONLY, DATA 
24 .eh_frame_hdr 0004765c 01934650 01934650 018ec650 2**2 
       CONTENTS, ALLOC, LOAD, READONLY, DATA 
25 .eh_frame  00128fec 0197bcac 0197bcac 01933cac 2**2 
       CONTENTS, ALLOC, LOAD, READONLY, DATA 
26 .gcc_except_table 000aaaf1 01aa4c98 01aa4c98 01a5cc98 2**2 
       CONTENTS, ALLOC, LOAD, READONLY, DATA 
27 .tbss   00000004 01b5078c 01b5078c 01b0778c 2**2 
       ALLOC, THREAD_LOCAL 
28 .ctors  000004f4 01b5078c 01b5078c 01b0778c 2**2 
       CONTENTS, ALLOC, LOAD, DATA 
29 .dtors  000004d0 01b50c80 01b50c80 01b07c80 2**2 
       CONTENTS, ALLOC, LOAD, DATA 
30 .jcr   00000004 01b51150 01b51150 01b08150 2**2 
       CONTENTS, ALLOC, LOAD, DATA 
31 .data.rel.ro 00012160 01b51160 01b51160 01b08160 2**5 
       CONTENTS, ALLOC, LOAD, DATA 
32 .dynamic  00000240 01b632c0 01b632c0 01b1a2c0 2**2 
       CONTENTS, ALLOC, LOAD, DATA 
33 .got   00002e6c 01b63500 01b63500 01b1a500 2**2 
       CONTENTS, ALLOC, LOAD, DATA 
34 .data   000481a8 01b66380 01b66380 01b1d380 2**5 
       CONTENTS, ALLOC, LOAD, DATA 
35 .got.plt  00001bc0 01bae528 01bae528 01b65528 2**2 
       CONTENTS, ALLOC, LOAD, DATA 
36 BINKDATA  00002de0 01bb0100 01bb0100 01b67100 2**5 
       CONTENTS, ALLOC, LOAD, DATA 
37 .bss   0046f8e8 01bb2ee0 01bb2ee0 01b69ee0 2**5 
       ALLOC 
38 BINKBSS  000067a0 020227e0 020227e0 01b69ee0 2**5 
       ALLOC 
39 .comment  00002d95 00000000 00000000 01b69ee0 2**0 
       CONTENTS, READONLY 
40 .drectve  0000005d 00000000 00000000 01b6cc75 2**0 
       CONTENTS, READONLY 

Таким образом, если отладка была все удалены, что это разделы «.debug $ S» и «.debug $ F»?

ответ

0

Несмотря на свои названия, эти разделы не являются разделами отладки, по крайней мере, не в соответствии с их флагами. Вы заметите, что они имеют одинаковые флаги, CONTENTS, ALLOC, LOAD, READONLY, DATA, как ряд других разделов в исполняемом файле, например .rodata. Эти флаги говорят, что раздел предназначен для загрузки в память и использования в качестве данных. Команда strip не знает, нужны ли эти разделы или нет. Отмена раздела .rodata приведет к поломке вашей программы, что приведет к ее сбою при каждом запуске. Команда strip не знает, что отбрасывание разделов .debug$F и .debug$S не будет делать то же самое.

Обратите внимание, что в исполняемых файлах ELF обычно вы найдете разделы с именем .debug$F и debug$S. Информация отладки DWARF, обычно используемая в файлах ELF, хранится в разделах, имена которых начинаются с .debug_, а не .debug$. У них также есть флаг DEBUGGING (но не флаг LOAD), поэтому strip знает, что они отлаживают разделы и что он должен и может удалить. Разделы с этими именами обычно видны только в файлах PECOFF, созданных компиляторами Microsoft. Они содержат отладочную информацию в фирменном формате Microsoft.

Если вы можете определить, что эти разделы не содержат полезной информации и хотят избавиться от них, вы должны удалить их из объектных файлов перед связыванием. Поскольку они загружены в память, возможно, слишком поздно полностью удалить их после компоновки. Вы можете использовать команду, как objcopy -R ".debug$*" foo.o foo-stripped.o, а затем ссылку с foo-stripped.o вместо foo.o.

Возможно, вы также захотите снять секции .comment и .directve с исполняемого файла, так как эти разделы, возможно, не нужны. В частности, .directve - это еще одна секция PECOFF, которую вы обычно не видите в файлах ELF.

+0

спасибо за ваш ответ. Однако я не понимаю, когда вы говорите: «.debug $ S/F» и «.directive» - это разделы формата PECOFF, созданные Microsoft. Но я работаю над linux и использую gcc/g ++, так как они создаются? – Monku

+0

@Monku GCC/G ++ никогда не будет создавать разделы '.debug $' на любой платформе, если вы явно не укажете ему, чтобы создать раздел такого имени и сказать ему точно, что ему вставить (например, с помощью 'char __attribute __ ((раздел (".debug $ F"))) foo [] = "..."; '). Он создает только разделы '.directive' для целей Windows PECOFF. Таким образом, либо вы связываетесь с объектными файлами, созданными компилятором Microsoft, либо где-то ваш код явно сообщает GCC о создании этих разделов. Создание файла карты может помочь вам определить, какой из них. Передайте '-Wl, -Map = my_app.map' команду GCC, которую вы используете для создания исполняемого файла. –

Смежные вопросы