GNU bug report logs - #48907
Grafts cause discrepancies in debug symbols file names (debug symbols missing in GDB).

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 48907 <at> debbugs.gnu.org
Subject: bug#48907: Grafts cause discrepancies in debug symbols file names (debug symbols missing in GDB).
Date: Tue, 28 Sep 2021 11:45:03 +0200

Hi,

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

> Ludovic Courtès <ludo <at> 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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.