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