Re: GSoC 2026: Improving Rust debugging support in GDB

>>>>> Horne, Preston M via Gdb <[email protected]> writes:

> The area I'm drawn to initially is improving the experience of
> debugging Rust programs. I noticed that the GDB docs Rust section
> (https://sourceware.org/gdb/current/onlinedocs/gdb.html/Rust.html)
> lists several limitations, and I'd like to understand whether working
> on that kind of thing, or other Rust improvements, would be a
> realistic and useful GSoC project? I'm very comfortable with C++ as
> that is what I spent the majority of my undergraduate courses
> studying.

I think the main difficulty is that the major issues with Rust debugging
are all basically due to compiler holes -- the compiler not emitting
DWARF for various constructs.  This is why calls via traits don't always
work, why operator overloading doesn't work in gdb (really the same as
the trait issue), why some "local" name lookups fail, etc.

For bugs like that, you would have to fix the compiler first.  However
that's also non-trivial; for instance the trait issue means first
patching LLVM.

Also some of the problems mentioned in that node aren't really worth
fixing IMO.


So I guess it depends on what exactly you would envision doing.  And
maybe that's between you & your mentor (I have no idea how that works).


There's also the open Rust bugs:

https://sourceware.org/bugzilla/buglist.cgi?component=rust&list_id=102021&product=gdb&resolution=---

Some of these are probably reasonable to solve.  Like the "varobj" bug
(if it exists) would be useful for IDEs.  But it's kind of ugly
programming; varobj is arguably the currently worst code in gdb.

HTH,
Tom