* bug#39503: Supporting elf-debuginfod (debug symbol server)
@ 2020-02-07 23:07 Ludovic Courtès
2020-02-09 22:40 ` Mark Wielaard
0 siblings, 1 reply; 2+ messages in thread
From: Ludovic Courtès @ 2020-02-07 23:07 UTC (permalink / raw)
To: bug-Guix; +Cc: Mark Wielaard
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* bug#39503: Supporting elf-debuginfod (debug symbol server)
2020-02-07 23:07 bug#39503: Supporting elf-debuginfod (debug symbol server) Ludovic Courtès
@ 2020-02-09 22:40 ` Mark Wielaard
0 siblings, 0 replies; 2+ messages in thread
From: Mark Wielaard @ 2020-02-09 22:40 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: bug-Guix
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-02-09 22:42 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-02-07 23:07 bug#39503: Supporting elf-debuginfod (debug symbol server) Ludovic Courtès
2020-02-09 22:40 ` Mark Wielaard
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.