build-ids, .debug_sup and other IDs (Was: [PATCH] Handle DWARF 5 separate debug sections)

[Mark Wielaard <mark@klomp.org>]

Hi,

I am adding the elfutils and dwz mailinglists to CC because I think
you stumbled upon a silent assumption debuginfod makes which would
be good to make explicit (or maybe change?)

Context is that dwz 0.15 (still not released yet) can now produce
standardized DWARF Supplementary Files using a .debug_sup section
when using --dwarf-5 -m multifile. See this bug report:
https://sourceware.org/bugzilla/show_bug.cgi?id=27440

The full patch to support that in gdb is here:
https://sourceware.org/pipermail/gdb-patches/2021-February/176508.html

But what I like to discuss is this part of Tom's email:

On Sun, Feb 21, 2021 at 04:18:10PM -0700, Tom Tromey wrote:
> DWARF 5 standardized the .gnu_debugaltlink section that dwz emits in
> multi-file mode.  This is handled via some new forms, and a new
> .debug_sup section.
> 
> This patch adds support for this to gdb.  It is largely
> straightforward, I think, though one oddity is that I chose not to
> have this code search the system build-id directories for the
> supplementary file.  My feeling was that, while it makes sense for a
> distro to unify the build-id concept with the hash stored in the
> .debug_sup section, there's no intrinsic need to do so.

Tom is correct. Technically a supplemental (alt) file id isn't a
build-id. But it does smell like one. It is a large globally unique
identifier that can be expressed as hex string. And the GNU extension
defining alt files for DWARF < 5 (and still with DWARF5 currently
by default because no consumer yet supports .debug_sup) will put
it in a .note.gnu.build-id NOTE section as GNU_BUILD_ID.

This has the nice side-effect that a distro will most likely make
it available as /usr/lib/debug/.build-id/xx/yyyy.debug file. And
that "build-id" is how you request it from debuginfod (you request
/buildid/BUILDID/debuginfo).

Now technically that is cheating and confusing two concepts,
the build-id and supplemental file id. But I was personally assuming
we would extend it to also to other things like dwo IDs (which are
again almost identical globally unique identifiers for files).
There one question would be if you would get the .dwo file or the
.dwp file in which is was embedded (I would vote for the second).

One consequence of conflating all these IDs is that it isn't immediately
clear what a debuginfod request for /buildid/BUILDID/executable should
return (probably nothing). Or if /buildid/BUILDID/source/SOURCE/FILE
requests also (should) work for other IDs than build-ids.

Any opinions on whether we should split these concepts out and introduce
separate request mechanisms per ID-kind, or simply assume a globally
unique id is globally unique and we just clarify what it means to use
a build-id, sup_checksum or dwo_id together with a request for an
executable, debuginfo or source/file?

Thanks,

Mark