Re: New feature "source-id"

Mark Wielaard
2014-03-18T13:22:12Z

Hi Gerhard,

On Sat, 2014-03-15 at 11:49 +0100, Gerhard Gappmeier wrote:
> The idea is that when you need to debug an executable or opening a coredump of
> an executable that was built with "source-id" and "build-id" enabled it just
> works. You don't need to care about how and where to get debug symbols and the
> correct sources.

I was wondering how this would work together with what distros like
Fedora do right now to solve this same issue of finding the
corresponding source files.

Distros, at least those based on rpm, rely on the build-id and DWARF
debug information. For each executable/library they record the build-id
and strip the symbol table and debug information in a separate .debug
file. The debug Compile Unit and DWARF line table reference the source
files used to build the executable file. These files are collected and
put under /usr/src/debug/<package-foo>/.... Then they run debugedit [1]
on the .debug files to replace all file references to the files
under /usr/src/debug/... Both the .debug files (placed
under /usr/lib/debug/<package-foo>) and the source files are then
bundled together in the <package-foo>-debuginfo.rpm (including the
necessary build-id directories).

That way you can use the build-id from the ELF note section to retrieve
both the separate .debug files and the corresponding source files. And
on my distro gdb even helpfully suggests how to do this:
Missing separate debuginfos, use: debuginfo-install at-3.1.13-14.fc20.x86_64
Which will then fetch the debuginfo package and all dependencies so gdb
can find the .debug files and the corresponding source code those .debug
files refer to. I don't know if the debuginfo-install suggestion is
upstream or only in the distro package of gdb.

> * We need to make the new section ".note.gnu.source-id" official. I don't know
> who maintains this and this needs to be registered somewhere.
> [...]
> * adding file hashes (SHA1) for each source file to the debug info. This way
> we can completely remove the mtime check and replace it with a check of the
> SHA1 sum. When we can replace the existing warning with a message like "The
> source file does not match the executable."

For DWARF5 there is a proposal to add the MD5 digest to debug-line file
table: http://dwarfstd.org/ShowIssue.php?issue=130701.1

Would that be a good alternative location to store the hash of the
source file?

Cheers,

Mark

[1] http://rpm.org/gitweb?p=rpm.git;a=blob;f=tools/debugedit.c;hb=HEAD