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
