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

[Fabian Grünbichler]

On Sat, 29 Nov 2025 20:39:43 +0000 John Scott <jscott at posteo.net> wrote:
> 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.

Hi!

thanks for your very detailed report!

> 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.

I will take a look at this, it makes sense in any case I think!

> 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?

Unfortunately it's not as simple. The commit hash there changes with each rustc version
(obviously), so the gdb-wrapper only works (properly) if RUSTC points at the version of
rustc used to compile the binary. It's main purpose after all is to pretty-print libstd
types, and libstd is statically linked into each rust-compiled binary (that uses it).

You can see what I mean if you install the Rust toolchain from trixie-backports and then
re-run your debugging session.

> 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.

See above for why that doesn't really help, unless we never change rustc in stable (including 
users installing from backports), and always compile all binaries with the same exact
version of rustc. I think the only proper way out would be to have versioned rust-gdb-XX
packages that embed the corresponding compiler hash, but I am not sure that's really worth
it..