Re: How can we decrease the cognitive overhead for contributors?

[Maxim Cournoyer]

Hi Csepp,

Csepp <raingloom@riseup.net> writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Hi,
>>
>> Csepp <raingloom@riseup.net> writes:
>>
>> [...]
>>
>>> but as soon as something breaks, you are thrown into the deep end,
>>> having to dissect logs, bisect commit ranges, learn strace, gdb (which
>>> still doesn't work well on Guix)
>>
>> Hm?  While GDB on Guix may be sometimes more challenging than say, on
>> Fedora, I only know of one problem, that is related to grafts (see: #48907).
>>
>> For running binaries wrapped in shell script, I have this 'run-gdb'
>> wrapper which reads:
>>
>> --8<---------------cut here---------------start------------->8---
>> #!/usr/bin/env bash
>>
>> wrapper=$(cat $(which $1))
>> shift
>> . <(echo "$wrapper" | grep ^export)
>> binary=$(echo "$wrapper" | grep ^exec | grep -o -E '/gnu/store[^"]*')
>> gdb --args "$binary" "$@"
>> --8<---------------cut here---------------end--------------->8---
>>
>> Hope that helps,
>
> Thanks, it does somewhat, but this is the kind of thing that should be
> either packaged in Guix, documented in the cookbook, or preferably fixed
> upstream.
> At the very least I try to document these helper Guix-specific helper
> scripts on the mailing list.  I've asked where it would be appropriate
> to put them (cookbook, package, guix module, etc) but I don't think I
> got a response.
> This is exactly what I mean by core devs having their own scripts that
> others don't have an easy way to find and/or access.

I think a "Debugging with GDB" section in the Cookbook showcasing such
script would be a good option.  Patches welcome!

> The other problem is the difficulty of accessing debug symbols.
> One problem is the need to recompile the package you need symbols for,
> the other is loading external symbols.  The first is a CI issue as far
> as I know: all the debug outputs would take up too much space
> (probably).

We have tons of disk space on Berlin, at least.  I don't think it'd be
an issue at least there (not sure about Bordeaux).  We could also look
into having our debug symbols de-duplicated with something like dwz
(https://sourceware.org/mailman/listinfo/dwz) to make them smaller, or
see if Fedora does something smart in this regard.

> This may not be fixable in the short term without
> additional funding.  The second is purely technical though.
> Maybe someone fixed it since the last time I tried to use GDB, but if
> not, it should be a priority IMHO.  Guix packages often have bugs and we
> should do everything in our power to make fixing future problems easier,
> otherwise the project risks the death of a thousand cuts.

Loading external (such as from linked libraries?) symbols should work,
provided they are in the profile you're working with, that gdb is there,
and that it has access to the default ~/.guile file (e.g. not in a
container), so that it automatically set 'debug-file-directory' for you,
from the GDB_DEBUG_FILE_DIRECTORY environment variable.

Also, build the profile with --no-grafts to avoid the bug mentioned
earlier (#48907).

-- 
Thanks,
Maxim