Maxim Cournoyer <maxim.courno...@gmail.com> writes:
> Hi, > > Csepp <raingl...@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? Why 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. 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). 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. This is why I chose to work on Mirage, to get a better understanding of the importer and cross-compilation tooling.
