[lldb-dev] ELF Separate Debug File question
Greg Clayton
gclayton at apple.com
Thu May 30 09:36:54 PDT 2013
This might be a dump question but: can you just load the "blah.debug" to begin with? You would create a Module with "/path/to/blah", but when the Module asks for its object file via Module::GetObjectFile(), could it not just make an object file using "blah.debug"? This would avoid the whole issue.
The main issue would be: is there anything missing in "blah.debug" that isn't in "blah"?
On May 29, 2013, at 6:50 PM, Michael Sartain <mikesart at valvesoftware.com> wrote:
> On Tue, May 28, 2013 at 9:40 AM, Greg Clayton <gclayton at apple.com> wrote:
> The only tricky thing you have to do is to have this second ObjectFileELF create section/offset addresses using the sections from the Module's object file. I am not sure what these debug info files look like, or if they both have the same section definitions. On MacOSX, we have a copy of all the section definitions in the dSYM file so any symbols in the extra debug info will get mapped back to the actual sections from the main executable very easily. The dSYM file has a symbol table, the symbol table has a section index, so if and when we make symbols in this extra debug symbols object file, we use the actual section definitions from the actual object file.
>
> First off, thank you for your reply Greg. Very useful as usual.
>
> The copying sections part seems less than ideal for these elf files. I've taken a very simple app (blah) and stripped the symbols (blah.debug). The section infos for both are down below.
>
> blah has stripped the .debug_* sections and bumped the following sections down. Plus the .shrstrtab (section names), .symtab (symbol table), and .strtab are all quite different. Several sections are in blah.debug but marked as having no data, so the offsets of the various sections would intersect if just copied.
>
> All those .debug sections are only used by ObjectFileELF::GetSymtab() and the routines it calls, yes? Is there anything gained by having an entirely separate SymbolVendorELF abstraction vs. just having ObjectFileELF do the searching and parsing of the .debug routines always - even if that means it loads a separate debug file? Or possibly sections could have a ObjectFileSP so they'll know where to read their data from? I'd (obviously) really like to avoid copying large amounts of data around...
>
> Thanks.
> -Mike
>
> blah:
> [Nr] Name Type Addr Off Size
> [ 0] NULL 000000 00000 000000
> [ 1] .interp PROGBITS 400238 00238 00001c
> [ 2] .note.ABI-tag NOTE 400254 00254 000020
> [ 3] .note.gnu.build-i NOTE 400274 00274 000024
> [ 4] .gnu.hash GNU_HASH 400298 00298 004cc0
> [ 5] .dynsym DYNSYM 404f58 04f58 00e550
> [ 6] .dynstr STRTAB 4134a8 134a8 026a80
> [ 7] .gnu.version VERSYM 439f28 39f28 00131c
> [ 8] .gnu.version_r VERNEED 43b248 3b248 0000d0
> [ 9] .rela.dyn RELA 43b318 3b318 0000a8
> [10] .rela.plt RELA 43b3c0 3b3c0 0009a8
> [11] .init PROGBITS 43bd68 3bd68 000018
> [12] .plt PROGBITS 43bd80 3bd80 000680
> [13] .text PROGBITS 43c400 3c400 075cf8
> [14] .fini PROGBITS 4b20f8 b20f8 00000e
> [15] .rodata PROGBITS 4b2120 b2120 00be00
> [16] .eh_frame_hdr PROGBITS 4bdf20 bdf20 00387c
> [17] .eh_frame PROGBITS 4c17a0 c17a0 01360c
> [18] .gcc_except_table PROGBITS 4d4dac d4dac 004f3d
> [19] .init_array INIT_ARRAY 6d9da0 d9da0 000038
> [20] .ctors PROGBITS 6d9dd8 d9dd8 000010
> [21] .dtors PROGBITS 6d9de8 d9de8 000010
> [22] .jcr PROGBITS 6d9df8 d9df8 000008
> [23] .dynamic DYNAMIC 6d9e00 d9e00 0001e0
> [24] .got PROGBITS 6d9fe0 d9fe0 000008
> [25] .got.plt PROGBITS 6d9fe8 d9fe8 000350
> [26] .data PROGBITS 6da338 da338 0000fc
> [27] .bss NOBITS 6da440 da434 000eb0
> [28] .comment PROGBITS 000000 da434 00005a
> [29] .gnu_debuglink PROGBITS 000000 da48e 000010
> [xx]
> [xx]
> [xx]
> [xx]
> [xx]
> [xx]
> [30] .shstrtab STRTAB 000000 da49e 00012b
> [31] .symtab SYMTAB 000000 dae10 0100b0
> [32] .strtab STRTAB 000000 eaec0 02c85f
>
> blah.debug:
> [Nr] Name Type Addr Off Size
> [ 0] NULL 000000 000000 000000
> [ 1] .interp NOBITS 400238 000238 00001c
> [ 2] .note.ABI-tag NOTE 400254 000254 000020
> [ 3] .note.gnu.build-i NOTE 400274 000274 000024
> [ 4] .gnu.hash NOBITS 400298 000298 004cc0
> [ 5] .dynsym NOBITS 404f58 000298 00e550
> [ 6] .dynstr NOBITS 4134a8 000298 026a80
> [ 7] .gnu.version NOBITS 439f28 000298 00131c
> [ 8] .gnu.version_r NOBITS 43b248 000298 0000d0
> [ 9] .rela.dyn NOBITS 43b318 000298 0000a8
> [10] .rela.plt NOBITS 43b3c0 000298 0009a8
> [11] .init NOBITS 43bd68 000298 000018
> [12] .plt NOBITS 43bd80 000298 000680
> [13] .text NOBITS 43c400 000298 075cf8
> [14] .fini NOBITS 4b20f8 000298 00000e
> [15] .rodata NOBITS 4b2120 000298 00be00
> [16] .eh_frame_hdr NOBITS 4bdf20 000298 00387c
> [17] .eh_frame NOBITS 4c17a0 000298 01360c
> [18] .gcc_except_table NOBITS 4d4dac 000298 004f3d
> [19] .init_array NOBITS 6d9da0 0d9da0 000038
> [20] .ctors NOBITS 6d9dd8 0d9da0 000010
> [21] .dtors NOBITS 6d9de8 0d9da0 000010
> [22] .jcr NOBITS 6d9df8 0d9da0 000008
> [23] .dynamic NOBITS 6d9e00 0d9da0 0001e0
> [24] .got NOBITS 6d9fe0 0d9da0 000008
> [25] .got.plt NOBITS 6d9fe8 0d9da0 000350
> [26] .data NOBITS 6da338 0d9da0 0000fc
> [27] .bss NOBITS 6da440 0d9da0 000eb0
> [28] .comment PROGBITS 000000 000298 00005a
> [29] .debug_aranges PROGBITS 000000 0002f2 001ca0
> [30] .debug_info PROGBITS 000000 001f92 295cc9
> [31] .debug_abbrev PROGBITS 000000 297c5b 01409a
> [32] .debug_line PROGBITS 000000 2abcf5 03881d
> [33] .debug_str PROGBITS 000000 2e4512 0f32f8
> [34] .debug_loc PROGBITS 000000 3d780a 1c031e
> [35] .debug_ranges PROGBITS 000000 597b28 08e7d0
> [36] .shstrtab STRTAB 000000 6262f8 000175
> [37] .symtab SYMTAB 000000 626e30 010440
> [38] .strtab STRTAB 000000 637270 02ca87
>
>
More information about the lldb-dev
mailing list