[Pkg-rust-maintainers] Bug#1121646: missing package dependency makes rust-gdb non-functional on typical installations (rustc command not found)

[John Scott]

Package: rust-gdb
Version: 1.85.0+dfsg3-1
Severity: important

Ahoy,
I'm experiencing this problem on the Trixie stable release (no backports), and I think this issue deserves a fix in a point release in any case. It may affect unstable.

GNOME Papers is a Rust application and I wanted to investigate a problem making it crash. A simple 'gdb papers' shows
> warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts of file /usr/bin/papers.
and by this it's referring to gdb_load_rust_pretty_printers.py. I learned that existing practice for a long time was to use a wrapper, rust-gdb, to debug Rust programs. The issue at https://github.com/rust-lang/rust/issues/111961 addresses the question of "Why do we need a Rust-specific GDB wrapper? How can we make GDB just do the right thing?" and the last blocker was the script not being designed to play nice with GDB after it's already started, and thus making auto-loading not work. That was fixed long, long ago (in Rust 1.72.0 as that issue shows) so in principle GDB is supposed to be able to do the right thing now. (Other libraries like GLib have scripts for pretty-printing and such that GDB can automagically find.)

However, even if a GDB user has correctly configured GDB to trust helper scripts that are installed system-wide, the rust-gdb package installs it in an esoteric location GDB would never know to look: to /usr/lib/rustlib/etc/gdb_load_rust_pretty_printers.py and this problem is clearly articulated at https://github.com/rust-lang/rust/issues/33159
To learn the places GDB does know to look by default, and thus the standard place GDB scripts should always be installed, one can do this:
$ gdb --batch  --ex 'show auto-load scripts-directory' --ex 'show debug-file-directory' --ex 'show data-directory'
List of directories from which to load auto-loaded scripts is $debugdir:$datadir/auto-load.
The directory where separate debug symbols are searched for is "/usr/lib/debug".
GDB's data directory is "/usr/share/gdb".

In practice Debian packages use the latter for this sort of thing, and I think this is the best choice anyway. See this random sampling from my system:
$ find  /usr/share/gdb/auto-load/ -name '*.py'
/usr/share/gdb/auto-load/lib/x86_64-linux-gnu/libc.so.6-gdb.py
/usr/share/gdb/auto-load/usr/lib32/libstdc++.so.6.0.33-gdb.py
/usr/share/gdb/auto-load/usr/lib/jvm/java-21-openjdk-amd64/jre/lib/server/libjvm.so-gdb.py
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33-gdb.py
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.2602.0-gdb.py
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.8400.4-gdb.py
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.8400.4-gdb.py
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libisl.so.23.4.0-gdb.py

One can see using readelf that GDB isn't told to look in a specialty subdirectory for the script:
$ readelf -p .debug_gdb_scripts /usr/bin/papers
String dump of section '.debug_gdb_scripts':
[1]	gdb_load_rust_pretty_printers.py

However, as https://sourceware.org/gdb/current/onlinedocs/gdb.html/Which-flavor-to-choose_003f.html documents, the .debug_gdb_scripts trick doesn't work all that well with static linking because GDB would only think to look in the source directory for Papers, and the Papers executable doesn't appear to even embed an absolute source path. In the future it would probably be best to make Rust packages in Debian set .debug_gdb_scripts to an absolute path like '/usr/share/gdb/auto-load/gdb_load_rust_pretty_printers.py' and install the file there, assuming GDB can tolerate an absolute path. Solutions are being discussed upstream at https://github.com/rust-lang/rust/issues/33159 but I don't think anyone is working on this.

Anywho, for typical Debian users like those using Trixie and who perhaps need to submit a bug report or dive into an issue on a production machine, rust-gdb is existing practice has its place. The problem is the rust-gdb script doesn't work on a normal system at all:
$ rust-gdb
/usr/bin/rust-gdb: 14: rustc: not found

Indeed, the rust-gdb binary package has gdb as its sole dependency and no Recommends. However /usr/bin/rust-gdb really is just a 28-line shell script wrapper around GDB: "What could the Rust compiler possibly be necessary for?" I wondered. And here it is:

# Find out where the pretty printer Python module is
RUSTC_SYSROOT="$("$RUSTC" --print=sysroot)"
GDB_PYTHON_MODULE_DIRECTORY="$RUSTC_SYSROOT/lib/rustlib/etc"
# Get the commit hash for path remapping
RUSTC_COMMIT_HASH="$("$RUSTC" -vV | sed -n 's/commit-hash: \([a-zA-Z0-9_]*\)/\1/p')"

So all that the compiler is needed for is to get versioning information! A typical user won't have the compiler even after installing the rust-gdb binary package so this script is broken for them. However, because the rust-gdb binary package is built by the rustc source package anyway, how about computing the "sysroot" (currently '/usr') and "commit hash" (on my system being '4d91de4e48198da2e33413efdcd9cd2cc0c46688') at build-time and baking them into the shell script?
For the sake of moving on to my original aim (debugging GNOME Papers) I installed rustc, and now the rust-gdb script is working. Someone who doesn't compile Rust code but is "merely" a user is unlikely to have it or dig more, and throughout Trixie's life span this would become a problem. Even if the only difference between invoking GDB and rust-gdb is the pretty-printer as it seems, informed folks know that rust-gdb is supposed to be the tool for this job, and it'll be useless more often than not.

In conclusion, rust-gdb should have had a hard dependency on the rustc package all along, but since this is needing a fix-up anyway, simply patching the rust-gdb shell script to use pre-computed versioning information (as if the command substitution were evaluated at package build time), instead of invoking rustc at runtime, will save users a lot of trouble.

Let me know if you prepare a draft upload and would like me to give it a try. I don't really know anything about Rust so I'm not in a position to take responsibility for this matter, however.

-- System Information:
Debian Release: 13.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.12.57+deb13-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rust-gdb depends on:
ii  gdb  16.3-1

rust-gdb recommends no packages.

Versions of packages rust-gdb suggests:
pn  gdb-doc  <none>

-- no debconf information
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20251129/26e1d930/attachment-0001.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6270 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20251129/26e1d930/attachment-0001.p7s>