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

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

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>>> Yikes!  This means that debugging with grafts (with the aid of debugging
>>> symbols) is no longer possible, right?
>>
>> It depends on whether the separate “debug” output gets grafted or not,
>> but yeah, if a dependency tree has this shape (app -> lib + lib:debug),
>> running ‘guix install app’ alone will prevent you from getting debugging
>> symbols from ‘lib:debug’ I believe.  That sucks.
>>
>> I wonder if we should revert 482fda2729c3e76999892cb8f9a0391a7bd37119.
>> It’s often not very helpful anyway (we often find ourselves downloading
>> unnecessary package outputs because of grafting).
>
> Hmm.  Perhaps.  But it'd also suck to have to download 1 GiB of unneeded
> debugging symbols to just apply a graft to Qt, for example.

Yeah.  That’s already the case in some cases though, that’s what I
meant.

>>> I remember reading about a 2nd option to locate the separate debug
>>> symbol files with GDB in info '(gdb) Separate Debug Files':
>>>
>>>
>>>    * The executable contains a "build ID", a unique bit string that is
>>
>> We’d have to check if this is applicable.  Looking at the ld manual
>> (info "(ld) Options"), it seems that the UUID “style” is ruled out
>> because it’s non-deterministic, and the md5 and sha1 styles would
>> require us to rewrite build IDs IIUC, similar to how we rewrite CRCs.
>
> Seems like it could work?  simark from #gdb says it should be
> deterministic for reproducible builds.  We'd need to fixup the grafted
> debug output, but they could being done in a separate derivation would
> no longer matter (as the debug symbols would be matched on a unique ID
> that is not linked to that derivation, not on their file name, which
> is).
>
> Did I get the above right?

To summarize, ‘.gnu_debuglink’ in executables/libraries contains the
CRC of the debug file.

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.

Am I right?

(BTW, I just noticed build IDs were also discussed at
<https://issues.guix.gnu.org/25752>.)

Ludo’.