Grafts cause discrepancies in debug symbols file names (debug symbols missing in GDB).

OpenSubmitted by Maxim Cournoyer.
Details
2 participants
  • Ludovic Courtès
  • Maxim Cournoyer
Owner
unassigned
Severity
important
M
M
Maxim Cournoyer wrote on 7 Jun 20:19 +0200
Debug symbols file name discrepancies
(name . bug-guix)(address . bug-guix@gnu.org)
87r1hdtu4t.fsf@gmail.com
Hello,
While attempting to debug a crash in jami-qt, I've noticed that GDBwould fail to load the symbol tables of the shared libraries it uses,for example qtdeclarative.
It seems that grafts are to blame. Let's start by looking at the debugfiles found for the qtdeclarative libQt5Qml.so.5 shared library:
Toggle snippet (27 lines)$ 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.2substituting /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.drvapplying 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 theactual shared library file name. Next, let's verify which qtdeclarativeshared libraries jami-qt is dynamically linked against:
Toggle snippet (7 lines)$ 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)
Oops! The actual store file name of the libQt5Qml.so.5 known to jami-qtis *not* the same as the one obtained earlier, which explains why GDBdoesn't find its symbols. Without grafts, the first command gives:
Toggle snippet (7 lines)$ guix build --no-grafts qtdeclarative | xargs -I{} find -L {} -name *libQt5Qml.so.5*/gnu/store/g1gxfbkyxilnx7s6mjdlj697y5n5wazn-qtdeclarative-5.15.2-debug/lib/debug/gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2/lib/libQt5Qml.so.5.15.2.debug/gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2/lib/libQt5Qml.so.5/gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2/lib/libQt5Qml.so.5.15/gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2/lib/libQt5Qml.so.5.15.2
Which still doesn't match the libraries jami-qt is linked with.
I'm out of ideas for now. Would someone have a clue?
Thank you!
Maxim
M
M
Maxim Cournoyer wrote on 7 Jun 21:26 +0200
(address . 48907@debbugs.gnu.org)
87mts1tr1u.fsf@gmail.com
Hello again,
Building everything without grafts does resolve the file namediscrepancy issue, e.g.:
guix build --no-grafts qtdeclarative | xargs -I{} find -L {} -name *libQt5Qml.so.5*/gnu/store/g1gxfbkyxilnx7s6mjdlj697y5n5wazn-qtdeclarative-5.15.2-debug/lib/debug/gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2/lib/libQt5Qml.so.5.15.2.debug/gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2/lib/libQt5Qml.so.5/gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2/lib/libQt5Qml.so.5.15/gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2/lib/libQt5Qml.so.5.15.2
guix build --no-grafts jami-qt | tail -1 | xargs -I{} ldd {}/bin/.jami-qt-real | grep qtdeclarative libQt5QuickWidgets.so.5 => /gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2/lib/libQt5QuickWidgets.so.5 (0x00007f42c79b2000) libQt5Quick.so.5 => /gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2/lib/libQt5Quick.so.5 (0x00007f42bfb52000) libQt5QmlModels.so.5 => /gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2/lib/libQt5QmlModels.so.5 (0x00007f42bface000) libQt5Qml.so.5 => /gnu/store/nvzvrr137qfqsn2875yrs9ilfd12wi96-qtdeclarative-5.15.2/lib/libQt5Qml.so.5 (0x00007f42bef59000)
And the debug symbols are now discovered and usable by GDB. So thisissue is indeed caused by grafts.
Maxim
M
M
Maxim Cournoyer wrote on 7 Jun 21:28 +0200
control message for bug #48907
(address . control@debbugs.gnu.org)
87lf7ltqyd.fsf@gmail.com
retitle 48907 Grafts cause discrepancies in debug symbols file names (debug symbols missing in GDB).quit
L
L
Ludovic Courtès wrote on 18 Jun 11:29 +0200
Re: bug#48907: Debug symbols file name discrepancies
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 48907@debbugs.gnu.org)
87eeczikq5.fsf@gnu.org
Hi,
Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
Toggle quote (37 lines)> $ 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’, thegrafting derivation dismisses the “debug” output of qtdeclarative, sincejami-qt does not depend on it. That way it doesn’t have tobuild/download and graft qtdeclarative:debug.
Conversely, when you run ‘guix build qtdeclarative’, it grafts bothoutputs of qtdeclarative. Thus, this grafting derivation is differentfrom the one jami-qt.drv depends on.
This behavior was implemented in commit482fda2729c3e76999892cb8f9a0391a7bd37119. Not sure what a good solutionwould be.
Thoughts?
Ludo’.
M
M
Maxim Cournoyer wrote on 24 Sep 04:32 +0200
Re: bug#48907: Grafts cause discrepancies in debug symbols file names (debug symbols missing in GDB).
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 48907@debbugs.gnu.org)
87ilyqk8jg.fsf_-_@gmail.com
Hi!
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (56 lines)> 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 debuggingsymbols) is no longer possible, right?
I remember reading about a 2nd option to locate the separate debugsymbol 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 befile name agnostic; the debug files would be matched by an internal IDthat they got at build time rather than from their file names (whichdoesn't work with the current different derivations in the presence ofgrafts).
Perhaps it'd also lift the need to recompute the CRC checksum of thedebug links produced when grafting!
HTH!
Maxim
L
L
Ludovic Courtès wrote on 24 Sep 16:07 +0200
control message for bug #48907
(address . control@debbugs.gnu.org)
87sfxum5i2.fsf@gnu.org
severity 48907 importantquit
L
L
Ludovic Courtès wrote on 24 Sep 16:14 +0200
Re: bug#48907: Grafts cause discrepancies in debug symbols file names (debug symbols missing in GDB).
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 48907@debbugs.gnu.org)
87lf3mm560.fsf@gnu.org
Hi,
Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
Toggle quote (2 lines)> Ludovic Courtès <ludo@gnu.org> writes:
[...]
Toggle quote (5 lines)>> 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.
[...]
Toggle quote (3 lines)> Yikes! This means that debugging with grafts (with the aid of debugging> symbols) is no longer possible, right?
It depends on whether the separate “debug” output gets grafted or not,but yeah, if a dependency tree has this shape (app -> lib + lib:debug),running ‘guix install app’ alone will prevent you from getting debuggingsymbols from ‘lib:debug’ I believe. That sucks.
I wonder if we should revert 482fda2729c3e76999892cb8f9a0391a7bd37119.It’s often not very helpful anyway (we often find ourselves downloadingunnecessary package outputs because of grafting).
Toggle quote (6 lines)> 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
We’d have to check if this is applicable. Looking at the ld manual(info "(ld) Options"), it seems that the UUID “style” is ruled outbecause it’s non-deterministic, and the md5 and sha1 styles wouldrequire us to rewrite build IDs IIUC, similar to how we rewrite CRCs.
Thanks,Ludo’.
M
M
Maxim Cournoyer wrote on 28 Sep 04:25 +0200
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 48907@debbugs.gnu.org)
87v92lh1wc.fsf@gmail.com
Heya,
Ludovic Courtès <ludo@gnu.org> writes:
[...]
Toggle quote (12 lines)>> Yikes! This means that debugging with grafts (with the aid of debugging>> symbols) is no longer possible, right?>> It depends on whether the separate “debug” output gets grafted or not,> but yeah, if a dependency tree has this shape (app -> lib + lib:debug),> running ‘guix install app’ alone will prevent you from getting debugging> symbols from ‘lib:debug’ I believe. That sucks.>> I wonder if we should revert 482fda2729c3e76999892cb8f9a0391a7bd37119.> It’s often not very helpful anyway (we often find ourselves downloading> unnecessary package outputs because of grafting).
Hmm. Perhaps. But it'd also suck to have to download 1 GiB of unneededdebugging symbols to just apply a graft to Qt, for example.
Toggle quote (11 lines)>> 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>> We’d have to check if this is applicable. Looking at the ld manual> (info "(ld) Options"), it seems that the UUID “style” is ruled out> because it’s non-deterministic, and the md5 and sha1 styles would> require us to rewrite build IDs IIUC, similar to how we rewrite CRCs.
Seems like it could work? simark from #gdb says it should bedeterministic for reproducible builds. We'd need to fixup the grafteddebug output, but they could being done in a separate derivation wouldno longer matter (as the debug symbols would be matched on a unique IDthat is not linked to that derivation, not on their file name, whichis).
Did I get the above right?
Thanks,
Maxim
L
L
Ludovic Courtès wrote on 28 Sep 11:45 +0200
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 48907@debbugs.gnu.org)
877df1f2zk.fsf@gnu.org
Hi,
Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
Toggle quote (19 lines)> Ludovic Courtès <ludo@gnu.org> writes:>> [...]>>>> Yikes! This means that debugging with grafts (with the aid of debugging>>> symbols) is no longer possible, right?>>>> It depends on whether the separate “debug” output gets grafted or not,>> but yeah, if a dependency tree has this shape (app -> lib + lib:debug),>> running ‘guix install app’ alone will prevent you from getting debugging>> symbols from ‘lib:debug’ I believe. That sucks.>>>> I wonder if we should revert 482fda2729c3e76999892cb8f9a0391a7bd37119.>> It’s often not very helpful anyway (we often find ourselves downloading>> unnecessary package outputs because of grafting).>> Hmm. Perhaps. But it'd also suck to have to download 1 GiB of unneeded> debugging symbols to just apply a graft to Qt, for example.
Yeah. That’s already the case in some cases though, that’s what Imeant.
Toggle quote (20 lines)>>> 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>>>> We’d have to check if this is applicable. Looking at the ld manual>> (info "(ld) Options"), it seems that the UUID “style” is ruled out>> because it’s non-deterministic, and the md5 and sha1 styles would>> require us to rewrite build IDs IIUC, similar to how we rewrite CRCs.>> Seems like it could work? simark from #gdb says it should be> deterministic for reproducible builds. We'd need to fixup the grafted> debug output, but they could being done in a separate derivation would> no longer matter (as the debug symbols would be matched on a unique ID> that is not linked to that derivation, not on their file name, which> is).>> Did I get the above right?
To summarize, ‘.gnu_debuglink’ in executables/libraries contains theCRC of the debug file.
Conversely, IIUC what the “normative parts of the output contents” (info"(ld) Options") really are, build IDs are computed on the code, not ondebug info.
But the problems remains the same I think: if you have/gnu/store/abc…/libfoo.so and /gnu/store/xyz…/libfoo.so, chances arethat they are different due to embedded store file names, and thus get adifferent build ID.
Am I right?
(BTW, I just noticed build IDs were also discussed athttps://issues.guix.gnu.org/25752.)
Ludo’.
L
L
Ludovic Courtès wrote on 28 Sep 12:28 +0200
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 48907@debbugs.gnu.org)
87lf3hdmeg.fsf@gnu.org
Ludovic Courtès <ludo@gnu.org> skribis:
Toggle quote (9 lines)> Conversely, IIUC what the “normative parts of the output contents” (info> "(ld) Options") really are, build IDs are computed on the code, not on> debug info.>> But the problems remains the same I think: if you have> /gnu/store/abc…/libfoo.so and /gnu/store/xyz…/libfoo.so, chances are> that they are different due to embedded store file names, and thus get a> different build ID.
We discussed this with Mark Wielaard on #guix¹, and one importanttakeaway is:
Toggle snippet (17 lines)<civodul> so gdb just checks that the separate debug file has the same build-id as the code, right? [12:16]<civodul> it doesn't matter whether it really is the sha1 of all those sections, does it?<mjw> that is kind of the whole point of the build-id, that it captures the whole build environment, not just the generated code, but also how it was generated (which is what the .debug sections kind of represent)<civodul> ok [12:17]<mjw> civodul, no, it doesn't need to be a hash over the actual bits produced. It can be a completely different hash, it can be a different number of bits (but not too short, they need to be globally unique).<civodul> ok, so we could have our own way of caculating build IDs [12:18]<mjw> civodul, all that really matters is that it uniquely identifies this binary blob. If any input, source, compiler, flags, etc. changes, it should be unique.
So I suspect that we would not need to rewrite build IDs upon grafting,and we could use the ungrafted debug info with grafted code and viceversa.
We should try it out to test the hypothesis, but if that works, that’dbe great.
Ludo’.
¹ https://logs.guix.gnu.org/guix/2021-09-28.log#114610
L
L
Ludovic Courtès wrote on 4 Oct 15:14 +0200
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 48907@debbugs.gnu.org)
8735phq6dy.fsf@gnu.org
Hi,
Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
Toggle quote (19 lines)> Ludovic Courtès <ludo@gnu.org> writes:>> [...]>>>> Yikes! This means that debugging with grafts (with the aid of debugging>>> symbols) is no longer possible, right?>>>> It depends on whether the separate “debug” output gets grafted or not,>> but yeah, if a dependency tree has this shape (app -> lib + lib:debug),>> running ‘guix install app’ alone will prevent you from getting debugging>> symbols from ‘lib:debug’ I believe. That sucks.>>>> I wonder if we should revert 482fda2729c3e76999892cb8f9a0391a7bd37119.>> It’s often not very helpful anyway (we often find ourselves downloading>> unnecessary package outputs because of grafting).>> Hmm. Perhaps. But it'd also suck to have to download 1 GiB of unneeded> debugging symbols to just apply a graft to Qt, for example.
Yeah. That’s already the case in some cases though, that’s what Imeant.
Toggle quote (20 lines)>>> 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>>>> We’d have to check if this is applicable. Looking at the ld manual>> (info "(ld) Options"), it seems that the UUID “style” is ruled out>> because it’s non-deterministic, and the md5 and sha1 styles would>> require us to rewrite build IDs IIUC, similar to how we rewrite CRCs.>> Seems like it could work? simark from #gdb says it should be> deterministic for reproducible builds. We'd need to fixup the grafted> debug output, but they could being done in a separate derivation would> no longer matter (as the debug symbols would be matched on a unique ID> that is not linked to that derivation, not on their file name, which> is).>> Did I get the above right?
To summarize, ‘.gnu_debuglink’ in executables/libraries contains theCRC of the debug file.
Conversely, IIUC what the “normative parts of the output contents” (info"(ld) Options") really are, build IDs are computed on the code, not ondebug info.
But the problems remains the same I think: if you have/gnu/store/abc…/libfoo.so and /gnu/store/xyz…/libfoo.so, chances arethat they are different due to embedded store file names, and thus get adifferent build ID.
Am I right?
(BTW, I just noticed build IDs were also discussed athttps://issues.guix.gnu.org/25752.)
Ludo’.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send email to 48907@debbugs.gnu.org