Re: Detecting separate debuginfo

[Florian Weimer <fweimer at redhat dot com>]

On 03/30/2014 11:23 AM, Mark Wielaard wrote:
> On Fri, Mar 28, 2014 at 02:00:49PM +0100, Florian Weimer wrote:
>> I maintain a database which extracts symbol information from ELF objects
>> (among other things).  I would like to enrich that with DWARF producer
>> data, and perhaps additional DWARF information in the future.
>>
>> I'd really like to avoid importing the ELF symbol information twice,
>> once from the real object file, and once from the separate debuginfo.
>
> Note that in general the main ELF file contains only a subset of the ELF
> symbols in .dynsym, or the compressed .gnu_debugdata section (which only
> contains function symbols), that the separate .debugdata file contains
> in the full .symtab. To get the full symbol table you can ignore main
> ELF file if you know there should be a corresponding .debug file (because
> the main ELF file has a .gnu_debuglink section).

Thanks, I only load the .dynsym section now.  It's not present in 
separate debuginfo, so it keeps the data duplication to a minimum right now.

> You can use the build-id to check whether two files describe the same
> module. Use eu-unstrip -n -e <file> to see it and the possible separate
> .debug file if it has some (that will show the file based location, but
> at least you know whether it should exist).

Indeed, I was already keeping that.

>> Based on the previous discussion around program interpreter reporting in
>> readelf, there is no easy way to detect separate debuginfo to trigger
>> special processing for it (e.g., do not extract symbols, only
>> DW_at_producer data).
>
> It isn't easy to detect whether the program headers of an ELF file are
> valid, although Roland suggested an heuristic to detect if they are.

BTW, I verified the program interpreter heuristic in readelf and it 
really works well.  It doesn't suppress any valid interpreters, and the 
code no longer reports any garbage interpreters, either.  I checked this 
Fedora and CentOS 5 binaries.

> But it is easy to detect whether a file had debuginfo (just check for a
> .debug_info section or just try opening the Elf with libdw dwarf_begin).
> And if it doesn't then just check to see if there is a .gnu_debuglink
> section to see if it has separate debuginfo (and a separate full symbol
> table).

Ahh, good points.  I'm doing both right now, attempting dwarf_begin and 
looking at .gnu_debuglink.

I think these suggestions helped me to solve my immediate needs.  I 
started using libdw and see some unexpected results (mostly missing data 
for attributes).  I guess I'll be back soon with more questions.

-- 
Florian Weimer / Red Hat Product Security Team