bug#48907: Grafts cause discrepancies in debug symbols file names (debug symbols missing in GDB).

["Ludovic Courtès" <ludo@gnu.org>]

Ludovic Courtès <ludo@gnu.org> skribis:

> Conversely, IIUC what the “normative parts of the output contents” (info
> "(ld) Options") really are, build IDs are computed on the code, not on
> debug info.
>
> But the problems remains the same I think: if you have
> /gnu/store/abc…/libfoo.so and /gnu/store/xyz…/libfoo.so, chances are
> that they are different due to embedded store file names, and thus get a
> different build ID.

We discussed this with Mark Wielaard on #guix¹, and one important
takeaway is:

--8<---------------cut here---------------start------------->8---
<civodul> so gdb just checks that the separate debug file has the same
	  build-id as the code, right?  [12:16]
<civodul> it doesn't matter whether it really is the sha1 of all those
	  sections, does it?
<mjw> that is kind of the whole point of the build-id, that it captures the
      whole build environment, not just the generated code, but also how it
      was generated (which is what the .debug sections kind of represent)
<civodul> ok  [12:17]
<mjw> civodul, no, it doesn't need to be a hash over the actual bits
      produced. It can be a completely different hash, it can be a different
      number of bits (but not too short, they need to be globally unique).
<civodul> ok, so we could have our own way of caculating build IDs  [12:18]
<mjw> civodul, all that really matters is that it uniquely identifies this
      binary blob. If any input, source, compiler, flags, etc. changes, it
      should be unique.
--8<---------------cut here---------------end--------------->8---

So I suspect that we would not need to rewrite build IDs upon grafting,
and we could use the ungrafted debug info with grafted code and vice
versa.

We should try it out to test the hypothesis, but if that works, that’d
be great.

Ludo’.

¹ https://logs.guix.gnu.org/guix/2021-09-28.log#114610