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

From: Maxim Cournoyer <[email-masked]>
Date: Mon, 27 Sep 2021 22:25:39 -0400

Heya,

Ludovic Courtès <[email-masked]> 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.

>> 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?

Thanks,

Maxim