[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#48907: Grafts cause discrepancies in debug symbols file names (debug
From: |
Maxim Cournoyer |
Subject: |
bug#48907: Grafts cause discrepancies in debug symbols file names (debug symbols missing in GDB). |
Date: |
Mon, 27 Sep 2021 22:25:39 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Heya,
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.
>> 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