Re: New feature "source-id"

Gerhard Gappmeier
2014-03-18T14:00:32Z

[-- Attachment #1: Type: text/plain, Size: 3762 bytes --]

On Tuesday, March 18, 2014 02:22:04 PM you wrote:
> 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.

If I understood this right, this means whenever a software is built the
sources get archived with the debug symbols in an debuginfo RPM file.
This way the build-id is all you need to get the correct sources and debug
symbols.

However my idea is somewhat different and a little bit smarter IMO:
* The SHA1 id of a git repo gets stored in the source-id meta info when
building.
* There is no need of archiving the source files in RPM, deb, tar.gz or zip
files. We have them already in the version control system and we don't want to
duplicate the data
* This solution is independent from any package format.
* You can analyze coredumps of executables that you don't have on your system.
There is no need to install any RPM package for that. This way you can analyze
e.g. a crash within a Ubuntu package on a Fedora system.
* The fetch-script fetches only the sources required by GDB, not the complete
project.

>
> > * 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?
That's exactly what I proposed. Only that I proposed SHA1 instead of MD5, but
this doesn't matter.
If this is already in the DWARD standard we should use this feature and don't
reinvent the wheel.
Thx for this hint.
>
> Cheers,
>
> Mark
>
> [1] http://rpm.org/gitweb?p=rpm.git;a=blob;f=tools/debugedit.c;hb=HEAD

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]