So, I’m sorry to say it but @tromey will be started a new job come next Thursday and likely won’t have time to help with Rust debugging anymore. We need to discuss how we are going to maintain the current Rust debuginfo support.
I had a few thoughts:
Would there be interest in @tromey doing a kind of “intro to debugging support” talk? I was thinking we could do a video call where @tromey walks through how debuginfo works, where rust-lldb lives, etc. We could record it, too, for others to watch. Would people be into that? It would probably want to be sometime next week. I know I would want to watch!
Write-ups and roadmaps.@tromey has been taking time to dump the “current state” of their thought process into issues and so forth.
Are there people interested in owning this topic? This is a big question. I’m not sure how best to support said people but I do think it’s something that sort of needs to happen.
Should we remove some features? For example, if we can’t support rust-lldb, should we just stop shipping it? That would be very sad, however.
This topic is hard specifically because debugging story involves not only rustc, but also knowledge of multiple debug info formats, behaviour of the debuggers etc. It is hard for any single person to keep all that information in their head, especially if they are an unpaid contributor.
I’ll guess we’ll have to manage, but we might end up having to cut things here and there. I think making sure support for Rust in gdb/lldb upstream stays well maintained is one of the most important tasks.
I feel that native support for Rust in upstream debuggers is the ideal end-goal. I haven’t had to use rust-*db wrappers for a long time now, plain lldb/gdb works just fine for me. It might make sense to cut those wrappers and upstream what is possible/makes sense. That might reduce the maintenance burden, but most likely not by much. And we would still find ourselves looking for somebody to maintain Rust support in the external projects.
@tromey thanks for all your hard work and best of luck!
It is indeed hard! this is partly why I'd love for @tromey to try and lay out where all the moving parts are and why they are setup this way.
I don't quite know how much detail we can expect. I doubt there is time to dig into the guts of DWARF, for example, but hopefully we can at least get a flavor (and of course @michaelwoerister and @eddyb are to some extent familiar with some of this -- and probably others).
I don’t have time to actively work on these tools, but I’m familiar enough that I can help with maintenance, at least. I also have peers in our debugging team at Red Hat that I can pull in as needed.
Also, getting info about LLVM and debuginfo into the rustic guide would be fantastic. If @tromey is already planning to write stuff down, it would be great if they could do that in the form of a chapter.
First of all yes: Thanks for all the hard work you’ve put into the Rust debugging story, @tromey!
I think LLDB is the biggest problem here since upstream LLDB doesn’t take patches for supporting languages other than C/C++ (they recently removed support for Go and, IIRC, even Swift has to maintain its own fork). For GDB, Rust support is merged upstream.
I think a summary of the current state would be great:
which things are considered done and expected to work
which things are in the pipeline and would need finishing
what’s the plan for Rust using Dwarf, i.e. what’s the proposed encoding for traits, enums, etc. (some of this already in the compiler, but I’m not sure it’s documented anywhere).
One thought: Work on debuggers is something where companies that want to support Rust could do a lot of good. Especially if they already have people with experience with the said debuggers.
Bugs are entered for missing pieces in debuggers (gdb, lldb)
Basic expression evaluation works using Rust syntax
Printing most Rust objects correctly (some DSTs are still not handled -- no DWARF describing them)
Pipeline
Ship gdb via rustup (bug, PR). The idea here is to be able to make changes to Rust DWARF output and immediately ship a working debugger to users
Code sign lldb. See the bug. This may require some sort of Rust legal entity, I am not sure.
Add support for calls via impl Type to lldb. I started work on this but may not finish it. There's a WIP patch, see the bug.
Emit traits to the DWARF. See the bug. This is a multi-stage project:
Change LLVM to let Rust emit DW_TAG_inheritance for any type, and use this to link a type to the traits it implements. This part of LLVM is, unfortunately, quite ugly...
Change lldb and gdb to read this information and use it to enable calls via traits and possibly operator overloading
Change rustc to actually emit trait info
Once this is shipping, file a DWARF bug report to note the extension (DWARF currently says only structure types can have inheritance, but Rust needs it for any type)
There are many more debuginfo bugs in the Rust issues, but the above is roughly what I was planning to work on next.
Something else is that if the Rust mangling changes, then new demanglers will have to be written and landed in gdb and lldb (at least). I'd planned to tackle this at some point but hadn't started it.
Rust DWARF
Rust currently emits two extensions to DWARF:
vtables are associated with a concrete type using DW_AT_containing_type. AFAIK this is only documented in the LLVM source (and perhaps somewhere in gdb and lldb as well, I forget).
Tagless enum variants required an extension. There is a DWARF standards bug for this.
As mentioned above, traits will require a DWARF extension as well.
There are plenty of smaller things that could be done to the DWARF output (e.g., using DW_ATE_UTF for the char type, or using different tags for tuples and structs); but most of these aren't crucial.
Just saw this… Sad to see you go, @tromey! I hope you won’t disappear altogether.
I maintain a VSCode debugger extension, which is at least partially Rust-focused. In fact, it’s based on rust-lldb (the customized lldb fork, not the shell script) at the moment, so losing it would be very sad indeed . I hope @nikomatsakis has picked it only as an example.
I also did some work around rustc’s debug info emission parts a few years back. If there will be a debugging WG, I think I’d like to participate in some capacity.
Can one have too many working groups? The debugging story seems important enough to have it’s own dedicated working group set aside for it. I’d like to help (circumstances permitting), but I’m concious that I know how little I know of lldb and dwarf. I’d probably need baby tasks to get my teath stuck into things. I’m certain that I couldn’t do it alone, and I think this would be a good time to up the truck number from 1. I suspect there’s a lot of people passionate about debuggers out there - we ought to be able to round up a few brave souls into a group…
I think it is possible to have too many WGs if there are not enough people to man them. I think it would be good to have more WGs, but only if (1) there are at least two or three active members for each one and (2) at least two of those members are not actively participating in another WG.
. I hope