bug#19973: Grafts break debug outputs

[Timothy Sample]

Hi Ludo,

address@hidden (Ludovic Courtès) writes:

> Hello!
>
> address@hidden (Ludovic Courtès) skribis:
>
>> However, one very likely problem is that .debug files include a CRC of
>> the binary they correspond to (info "(gdb) Separate Debug Files"), and
>> that CRC is not updated when we graft things.
>>
>> We could change our grafting code to specifically address this problem
>> (using (guix elf) & co.).
>
> The patches below address this by adding code to update the CRC in the
> ‘.gnu_debuglink’ section upon grafting.  It uses a simple hook
> mechanism, a simplified version of what Timothy proposed.
>
> The ‘.gnu_debuglink’ hook does nothing for packages that lack a “debug”
> output.  For packages that have a “debug” output, only ELF files from
> bin/, lib/, etc. are considered.  Overall the run-time cost should be
> low.
>
> I tested it with guile-ssh on current master (commit
> bab4dc58f7278e481c7eb8c6f954d6f1751deb23).  When running:
>
>   guix build guile-ssh
>
> you see messages like this:
>
>   updating '.gnu_debuglink' CRC in
> '/gnu/store/523lgdnmr4x0q7cnn8wr7f2zzcnlvrpp-guile-ssh-0.11.3/lib/guile/2.2/site-ccache/ssh/tunnel.go'
>   updating '.gnu_debuglink' CRC in
> '/gnu/store/523lgdnmr4x0q7cnn8wr7f2zzcnlvrpp-guile-ssh-0.11.3/lib/guile/2.2/site-ccache/ssh/version.go'
>   updating '.gnu_debuglink' CRC in
> '/gnu/store/523lgdnmr4x0q7cnn8wr7f2zzcnlvrpp-guile-ssh-0.11.3/lib/libguile-ssh.so.11.0.0'
>
> The thing about .go files isn’t very useful (the ‘strip’ phase should
> ignore them in the first place probably).  However I’ve confirmed that
> gdb is happy with the grafted libguile-ssh.so: if you add breakpoints
> with “rb guile_ssh” and then call one of the guile-ssh procedures from
> the REPL, you see that you get proper debugging info and all (don’t
> forget to “set debug-file-directory” upfront.)
>
> That’s it!  It’s a relief to fix a 3-year old bug.  :-)
>
> Next we can fix build IDs similarly (see <https://bugs.gnu.org/25752>),
> and maybe the Racket CRC issue that Timothy and Chris looked at
> recently, and maybe the Java manifest issue as well (is it still
> relevant?).

The only concern I have is the level at which the hooks operate.  In my
draft patch¹ I had the hooks running both on the client side and the
build side.  This made it possible to get a bit more information about
the derivation being grafted.  If everything happens at the build level
based on outputs, we will only be able to look at the structures and
names of the outputs.

That being said, this is probably okay.  The Racket hook will just have
to check for “share/racket” to determine if it runs (and fail safely if
anything is amiss).

> Thanks,
> Ludo’.


-- Tim

¹ https://lists.gnu.org/archive/html/guix-devel/2018-08/msg00113.html