bug#48907: Grafts cause discrepancies in debug symbols file names (debug symbols missing in GDB).

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi!

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> $ guix build qtdeclarative | xargs -I{} find -L {} -name *libQt5Qml.so.5*
>> substitute: updating substitutes from 'http://127.0.0.1:8080'... 100.0%
>> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
>> The following files will be downloaded:
>>    /gnu/store/g1gxfbkyxilnx7s6mjdlj697y5n5wazn-qtdeclarative-5.15.2-debug
>>    /gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2
>> substituting /gnu/store/g1gxfbkyxilnx7s6mjdlj697y5n5wazn-qtdeclarative-5.15.2-debug...
>> downloading from https://ci.guix.gnu.org/nar/lzip/g1gxfbkyxilnx7s6mjdlj697y5n5wazn-qtdeclarative-5.15.2-debug ...
>>  qtdeclarative-5.15.2-debug  94.9MiB                            1.2MiB/s 01:21 [##################] 100.0%
>>
>> The following graft will be made:
>>    /gnu/store/djhcai9rixm2j3jlamwdhsgwgidg7w74-qtdeclarative-5.15.2.drv
>> applying 2 grafts for /gnu/store/djhcai9rixm2j3jlamwdhsgwgidg7w74-qtdeclarative-5.15.2.drv ...
>> grafting '/gnu/store/g1gxfbkyxilnx7s6mjdlj697y5n5wazn-qtdeclarative-5.15.2-debug' -> '/gnu/store/l3h4ka7v3j1yhik0f1phwch08a09p0bx-qtdeclarative-5.15.2-debug'...
>> grafting '/gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2' -> '/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2'...
>> updating '.gnu_debuglink' CRC in '/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/bin/qml'
>> updating '.gnu_debuglink' CRC in '/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/bin/q
>> [...]
>> updating '.gnu_debuglink' CRC in '/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/qt5/qml/QtQuick/Window.2/libwindowplugin.so'
>> updating '.gnu_debuglink' CRC in '/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/qt5/qml/QtTest/libqmltestplugin.so'
>> successfully built /gnu/store/djhcai9rixm2j3jlamwdhsgwgidg7w74-qtdeclarative-5.15.2.drv
>> /gnu/store/l3h4ka7v3j1yhik0f1phwch08a09p0bx-qtdeclarative-5.15.2-debug/lib/debug/gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/libQt5Qml.so.5.15.2.debug
>> /gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/libQt5Qml.so.5.15.2
>> /gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/libQt5Qml.so.5
>> /gnu/store/pryhgzb6cwnzsskqwldwc6dxr6nwnywf-qtdeclarative-5.15.2/lib/libQt5Qml.so.5.15
>>
>>
>> So far so good.  The file hierarchy under the debug output matches the
>> actual shared library file name.  Next, let's verify which qtdeclarative
>> shared libraries jami-qt is dynamically linked against:
>>
>> $ guix build jami-qt | tail -1 | xargs -I{} ldd {}/bin/.jami-qt-real | grep qtdeclarative
>>         libQt5QuickWidgets.so.5 => /gnu/store/mjl02yma4r5xjark6d8pp5h2j0a2vccs-qtdeclarative-5.15.2/lib/libQt5QuickWidgets.so.5 (0x00007fb9e38a8000)
>>         libQt5Quick.so.5 => /gnu/store/mjl02yma4r5xjark6d8pp5h2j0a2vccs-qtdeclarative-5.15.2/lib/libQt5Quick.so.5 (0x00007fb9dba47000)
>>         libQt5QmlModels.so.5 => /gnu/store/mjl02yma4r5xjark6d8pp5h2j0a2vccs-qtdeclarative-5.15.2/lib/libQt5QmlModels.so.5 (0x00007fb9db9c3000)
>>         libQt5Qml.so.5 => /gnu/store/mjl02yma4r5xjark6d8pp5h2j0a2vccs-qtdeclarative-5.15.2/lib/libQt5Qml.so.5 (0x00007fb9dae4e000)
>
> This is due to the fact that, when you run ‘guix build jami-qt’, the
> grafting derivation dismisses the “debug” output of qtdeclarative, since
> jami-qt does not depend on it.  That way it doesn’t have to
> build/download and graft qtdeclarative:debug.
>
> Conversely, when you run ‘guix build qtdeclarative’, it grafts both
> outputs of qtdeclarative.  Thus, this grafting derivation is different
> from the one jami-qt.drv depends on.
>
> This behavior was implemented in commit
> 482fda2729c3e76999892cb8f9a0391a7bd37119.  Not sure what a good solution
> would be.
>
> Thoughts?

Yikes!  This means that debugging with grafts (with the aid of debugging
symbols) is no longer possible, right?

I remember reading about a 2nd option to locate the separate debug
symbol files with GDB in info '(gdb) Separate Debug Files':


   * The executable contains a "build ID", a unique bit string that is
     also present in the corresponding debug info file.  (This is
     supported only on some operating systems, when using the ELF or PE
     file formats for binary files and the GNU Binutils.)  For more
     details about this feature, see the description of the '--build-id'
     command-line option in *note Command Line Options: (ld)Options.
     The debug info file's name is not specified explicitly by the build
     ID, but can be computed from the build ID, see below.

   [...]
   
   * For the "build ID" method, GDB looks in the '.build-id'
     subdirectory of each one of the global debug directories for a file
     named 'NN/NNNNNNNN.debug', where NN are the first 2 hex characters
     of the build ID bit string, and NNNNNNNN are the rest of the bit
     string.  (Real build ID strings are 32 or more hex characters, not
     10.)

What may help us here, compared to debug links, is that it seems to be
file name agnostic; the debug files would be matched by an internal ID
that they got at build time rather than from their file names (which
doesn't work with the current different derivations in the presence of
grafts).

Perhaps it'd also lift the need to recompute the CRC checksum of the
debug links produced when grafting!

HTH!

Maxim