strange section types in libgcc_s.so on veyron_minnie |
||
Issue descriptionWhile looking at crbug.com/665083, I found objdump cannot disassemble libgcc_s.so with -d. It seems that objdump doesn't like it's .text to be of the type NOBITS. Although I'm not sure if this directly caused 665083, it looks weird to me and may prevent breakpad from resolving the stack traces. Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .note.gnu.build-i NOTE 00000114 000114 000024 00 A 0 0 4 [ 2] .gnu.hash NOBITS 00000138 000138 002674 04 A 0 0 4 [ 3] .dynsym NOBITS 000027ac 000138 004ad0 10 A 0 3 4 [ 4] .dynstr NOBITS 0000727c 000138 004f7b 00 A 0 0 1 [ 5] .gnu.version NOBITS 0000c1f8 000138 00095a 02 A 0 0 2 [ 6] .gnu.version_d NOBITS 0000cb54 000138 0001bc 00 A 0 13 4 [ 7] .gnu.version_r NOBITS 0000cd10 000138 000020 00 A 0 1 4 [ 8] .rel.dyn NOBITS 0000cd30 000138 000080 08 A 0 0 4 [ 9] .rel.plt NOBITS 0000cdb0 000138 000178 08 A 0 0 4 [10] .init NOBITS 0000cf28 000138 00000c 00 AX 0 0 4 [11] .plt NOBITS 0000cf34 000138 000280 04 AX 0 0 4 [12] .text NOBITS 0000d1b8 000138 00b0a8 00 AX 0 0 8 [13] .fini NOBITS 00018260 000138 000008 00 AX 0 0 4 [14] .rodata NOBITS 00018268 000138 000200 00 A 0 0 4 [15] .ARM.extab NOBITS 00018468 000138 000024 00 A 0 0 4 [16] .ARM.exidx NOBITS 0001848c 000138 000120 00 AL 12 0 4 [17] .eh_frame NOBITS 000185ac 000138 000004 00 A 0 0 4 [18] .init_array NOBITS 00020df0 000df0 000004 00 WA 0 0 4 [19] .fini_array NOBITS 00020df4 000df0 000004 00 WA 0 0 4 [20] .jcr NOBITS 00020df8 000df0 000004 00 WA 0 0 4 [21] .dynamic NOBITS 00020dfc 000df0 000108 08 WA 0 0 4 [22] .got NOBITS 00020f04 000df0 0000fc 04 WA 0 0 4 [23] .data NOBITS 00021000 000df0 000004 00 WA 0 0 4 [24] .bss NOBITS 00021004 000df0 000038 00 WA 0 0 4 [25] .comment PROGBITS 00000000 000138 000027 01 MS 0 0 1 [26] .ARM.attributes ARM_ATTRIBUTES 00000000 00015f 000033 00 0 0 1 [27] .debug_aranges PROGBITS 00000000 000198 00c3c0 00 0 0 8 [28] .debug_info PROGBITS 00000000 00c558 089ba5 00 0 0 1 [29] .debug_abbrev PROGBITS 00000000 0960fd 02d2b1 00 0 0 1 [30] .debug_line PROGBITS 00000000 0c33ae 028787 00 0 0 1 [31] .debug_frame PROGBITS 00000000 0ebb38 009bf8 00 0 0 4 [32] .debug_str PROGBITS 00000000 0f5730 00616b 01 MS 0 0 1 [33] .debug_loc PROGBITS 00000000 0fb89b 01b5d0 00 0 0 1 [34] .debug_ranges PROGBITS 00000000 116e6b 0002b0 00 0 0 1 [35] .shstrtab STRTAB 00000000 11711b 000174 00 0 0 1 [36] .symtab SYMTAB 00000000 117290 015d40 10 37 4394 4 [37] .strtab STRTAB 00000000 12cfd0 00609f 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific)
,
Mar 9 2017
I'm not sure if this causes some runtime problem. There might be two cases: 1. It doesn't cause a runtime problem. Even if it does, it happens rarely. 2. Functions in libgcc_s.so are rarely called. Otherwise we would see a lot of crashes once this was merged.
,
Mar 9 2017
section attributes do not matter to the runtime. look at the program headers to see what shows up. that said, i'm a big fan of section attributes being correct precisely because it confuses debugging tools otherwise.
,
Mar 9 2017
Sorry, I was looking at libgcc_s.so.1.debug, rather than the real libgcc_so.so.1 shipped. It shouldn't cause any runtime problem. I'm not sure if it can confuse other tools or not. (I assume no, because other *.debug has similar layouts, too) |
||
►
Sign in to add a comment |
||
Comment 1 by cmt...@chromium.org
, Mar 9 2017