Hi Ludo,
On Sat, Feb 08, 2020 at 12:07:22AM +0100, Ludovic Courtès wrote:
Toggle quote (5 lines)
> 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/
Toggle quote (3 lines)
> 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 :)
Toggle quote (3 lines)
> 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).
Toggle quote (6 lines)
> 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.
Toggle quote (3 lines)
> PS: I found Eelco Dolstra’s dwarffs to be very smart, too!
> https://github.com/edolstra/dwarffs
After the talk I also learned about:
