gdb on my Rust debug executable finds my own files fine, but not files in crates loaded from crates.io. How do I get it to look at those crates?
(Ubuntu Linux 22.04 LTS, gdb 12.1)
Tried Microsoft's LLM for advice.
It suggests
cargo install cargo-download
cargo download crate_name --version
This works, sort of. The crate is sent to standard output in tar.gz format, but that can be dealt with.
Then
directory PATHNAME
adds PATHNAME to the file search list. I can now type
list capture.rs:188
and see source from the library crate. Fine. But if I try
break capture.rs:188
I get
No line 188 in file "capture.rs".
Make breakpoint pending on future shared library load?
Hm. It just displayed that source code. Looking up that message, I find bug reports from 2011 or so, but not much current.
This is basic "gdb", no config files or special options, program compiled with cargo build --examples. There's probably something extra I have to do, but I can't find it.
Is this on the same machine as you built the executable? And are you using remap-path-prefix? If the answers to those questions are yes and no respectively, it should work out of the box as rustc by default uses absolute paths for dependencies in the debuginfo.
Yes, built on the same machine in the same place. Pure Rust.
The code is at GitHub - John-Nagle/ui-mock
branch "screenshot".
(I'm trying to figure out why, when I request a screenshot via the Rend3->egui->egui-wgpu->wgpu->winit->vulkan stack, the request goes in OK but the Screenshot event never comes back, and there are no errors reported. So I need to set breakpoints to see how far the request gets in the graphics stack before it gets lost.)
Still stuck on this. I've found references to this problem on Windows: [Solved] How to step into std source code when debugging in VS Code? - #8 by dcmorse, but I'm on Linux.
There's probably some incantation I need to use, but I don't know what it is and can't find any references.
Again, "list" can find the source file, but "break" cannot for the crate "egui-wgpu". Looked through the Cargo.toml files for that crate to see if any debug modes were disabled, but did not find anything.
A bit more info. Here's the gdb session:
rust-gdb ui-mock
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04.2) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Registered pretty printers for UE classes
Reading symbols from ui-mock...
(gdb) list capture.rs:100
95 });
96
97 (texture, padding, bind_group)
98 }
99
100 /// Updates the [`CaptureState`] if the size of the surface texture has changed
101 pub fn update(&mut self, device: &wgpu::Device, texture: &wgpu::Texture) {
102 if self.texture.size() != texture.size() {
103 let (new_texture, padding, bind_group) =
104 Self::create_texture(device, texture, &self.pipeline.get_bind_group_layout(0));
(gdb) break capture.rs:102
No line 102 in file "capture.rs".
Make breakpoint pending on future shared library load? (y or [n]) n
I've tried this with regular gdb and rust-gdb. I've tried to set breakpoints on many different lines, and that doesn't work. I've tried various workarounds with local copies of the crates . io crates, and they don't help. I can set breakpoints only on my own files, not ones from crates . io
Is this a gdb bug, or something in Rust land?
1 Like
Hi,
Are you sure that the symbol isn't removed at link time?
I tried
henrik@hyperion ~/s/r/ui-mock (main)> rust-objdump --demangle --syms target/debug/examples/ui-mock | rg egui_wgpu| rg update
000000000148d630 l F .text 0000000000000120 egui_wgpu::renderer::Renderer::update_texture::_$u7b$$u7b$closure$u7d$$u7d$::h93a3a5dc4b063397
000000000148d9c0 l F .text 0000000000000033 egui_wgpu::renderer::Renderer::update_texture::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h628e39e7c32ab546
000000000148faf0 l F .text 000000000000025d egui_wgpu::renderer::Renderer::update_buffers::_$u7b$$u7b$closure$u7d$$u7d$::h3bd45d2c1890cf65
000000000148d750 l F .text 000000000000026f egui_wgpu::renderer::Renderer::update_texture::_$u7b$$u7b$closure$u7d$$u7d$::hd98c6c1b750edf59
000000000148e360 g F .text 0000000000001787 egui_wgpu::renderer::Renderer::update_buffers::h38b7480f65de407b
000000000148c660 g F .text 0000000000000fc3 egui_wgpu::renderer::Renderer::update_texture::h60353d2c61bad392
and at least on my machine the update() function doesn't appear to be in the compiled binary. Same goes for the read_screen_rgba() in egui_wgpu/src/capture.rs:188. The file is included in info sources but the symbols simply don't appear to be there. Could it be behind a feature flag?
You're right. Many symbols are missing.
Is this associated with async functions? The symbols from egui_wgpu do not contain async functions such as "new". Look in winit.rs in egui-wgpu.
I found some instructions from 2020 on how to debug async, but they show the debugger finding the code by file and line number. I can't
Is there any possibility that the Rust legacy problem that crates can use "-" in names but symbols always use "_" confused things?
From experience I can say that it is usually not gdb that has a bug in it. In this case I'd double check that the symbols you're trying to add break points to actually get called. Try setting a breakpoint in your main() and step through the code and see if the call chain matches your expectations.
I haven't tried to debug async functions but I can imagine they might be a bit trickier to understand as the compiler turns the computation into a future and then you have an executor framework polling the future using one or more threads. I'd imagine gdb should still find the symbols provided they are included in the binary.
Comments from someone who has would help.
Async functions get moved around and have numeric names in the symbol list dump. Not sure how this works.