GNU bug report logs - #39503
Supporting elf-debuginfod (debug symbol server)

Previous Next

To reply to this bug, email your comments to 39503 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: bug-Guix <at> gnu.org
Subject: Supporting elf-debuginfod (debug symbol server)
Date: Sat, 08 Feb 2020 00:07:22 +0100

Hello Guix!

I’ve just watched Mark’s very nice talk about debuginfod and and I’d
like to work towards running an instance of it on ci.guix.gnu.org:

  https://fosdem.org/2020/schedule/event/debugging_debuginfod/

What’s missing today is configuring GCC with ‘--enable-linker-build-id’
(which is not the default, unlike what Mark says in the talk :-)).

If we do that, I wonder if we can stop using ‘.gnu_debuglink’ (see the
‘strip’ phase in (guix build gnu-build-system)).

Also, I suspect build IDs wouldn’t mesh well with grafting: unless we
rewrite them, the same build ID would match both the ungrafted and the
grafted variant.  Is that a problem?  Not sure.  (Currently (guix build
debug-link) recomputes ‘.gnu_debuglink’ upon grafting so that the links
remain valid.)

Thoughts?

Thanks,
Ludo’.

PS: I found Eelco Dolstra’s dwarffs to be very smart, too!
    https://github.com/edolstra/dwarffs

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mark Wielaard <mark <at> klomp.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: bug-Guix <at> gnu.org
Subject: Re: bug#39503: Supporting elf-debuginfod (debug symbol server)
Date: Sun, 9 Feb 2020 23:40:42 +0100

Hi Ludo,

On Sat, Feb 08, 2020 at 12:07:22AM +0100, Ludovic Courtès wrote:
> I’ve just watched Mark’s very nice talk about debuginfod and and I’d
> like to work towards running an instance of it on ci.guix.gnu.org:
> 
>   https://fosdem.org/2020/schedule/event/debugging_debuginfod/

Glad you liked it.

> What’s missing today is configuring GCC with ‘--enable-linker-build-id’
> (which is not the default, unlike what Mark says in the talk :-)).

It indeed isn't, I just believed it was because almost all distros
enable it by default, except for Guix :)

> If we do that, I wonder if we can stop using ‘.gnu_debuglink’ (see the
> ‘strip’ phase in (guix build gnu-build-system)).

debug consumers still need a way to resolve the build-ids.  The
debuginfod-client is one (new) way of doing it. But it will take some
time to add support to everything. Traditionally a debug file for a
build-id is resolved though the file system. That is a symlink under
/usr/lib/debug/.build-id/xx/yyyyy.debug that points to the actual
debug file. It is normally installed by the debuginfo package. For
guix some alternative location should be found and the debug consumers
should be patched to look there (if you want to get rid of
.gnu_debuglink).

> Also, I suspect build IDs wouldn’t mesh well with grafting: unless we
> rewrite them, the same build ID would match both the ungrafted and the
> grafted variant.  Is that a problem?  Not sure.  (Currently (guix build
> debug-link) recomputes ‘.gnu_debuglink’ upon grafting so that the links
> remain valid.)

I don't understand grafting yet. But if it is a different build, then
it needs a new/unique build-id.

> PS: I found Eelco Dolstra’s dwarffs to be very smart, too!
>     https://github.com/edolstra/dwarffs

After the talk I also learned about:
https://docs.01.org/clearlinux/latest/guides/clear/debug.html

Previous Next

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