Package gdb with Rust

[brson]

gdb has first-class support for Rust now, and two active maintainers (@tromey @Manishearth). Let's package it with Rust. This will have lots of advantages:

• All major platforms will get the same debugging experience
• Debuging will be more reliable because users have the exact debugger we've actually tested with our toolchain
• By controlling the producer and consumer of our DWARF we can evolve it quickly, move to Rust-specific DWARF

Steps:

• Set up a fork in rust-lang-nursery
• Modify it to produce a gdb with a Rust-specific name
• Set up CI and packaging for gdb
• Modify rust-buildbot / rust-packaging to add gdb to the manifest as an optional component
• Figure out the best user experience for obtaining gdb via rustup

cc @michaelwoerister @rust-lang/tools What you think?

[alexcrichton]

Sounds great to me, I'm all for it!

[vadimcn]

I can see where you are coming from, but long term, I'd rather see LLDB standardized for Rust. I've investigated both while developing my vscode debugger front-end and here's why I chose to go with LLDB:

• GDB only really works on Linux and even then not always (try interrupting a process via the MI API on OSX or Windows, for instance).
• LLDB is a part of LLVM toolchain, so they are much easier to co-develop.
• LLDB supports plugins, so there's a chance to use the actual Rust parser for expressions, rather than some hand-rolled approximation.
• LLDB has MSVC .pdb debug info support in the works; I haven't seen any plans to do that for GDB.
• LLDB has an actual API for embedding.

[Manishearth]

LLDB being standardized for rust can happen independently of this. I was thinking of working on it; but not sure of I will (won't have time; C++ is draining).

[Manishearth]

Also, until we figure out a story for DWARF in rust things are unstable anyway. We already hit the situation once where marking our binaries as DW_LANG_RUST broke lldb but was necessary for gdb to work.

[michaelwoerister]

I agree with the things that @vadimcn says but I don't think that these observations necessarily speak against providing a Rust-specific GDB version.

Here are some more questions:

1. What's the advantage of providing our own version of GDB versus just relying on Rust support getting merged upstream eventually?
2. Can we provide an ergonomic enough experience for people to actually use this?
3. How much maintenance effort would this mean?
4. And, more specifically regarding the co-evolution of DWARF and GDB, will we need a "debugger-tuning" flag in the compiler? (since, at least in the beginning, LLDB will still not know about Rust)

Here are some thoughts, but I'd also like to hear how other people would answer these questions:

1. (a) The main advantage I see is that more people would be able to profit from Rust support sooner. It can take quite a while until a change ends up in package managers and some people (like me) tend to keep using LTS versions and only upgrade when they have to.
   
   (b) @brson's point about providing one specific and well-tested version per platform also very good! That's something I had not thought about before.
2. This boils down to the questions if we can make something like rustup install rust-gdb just work on Linux and OSX and hopefully on Windows too, I think. I would hope that that is not too hard on Linux, but I don't know about OSX, and GDB on Windows is always a rather brittle thing in my experience.
3. I have no idea :)
4. We might not quite get around that. On the other hand, there is precedent for such compiler flags.

So, I think, I'm generally in favor of this if we can pull it off with reasonable effort.

[brson]

I can see where you are coming from, but long term, I'd rather see LLDB standardized for Rust.

I agree LLDB is more promising in the long-run, but think we should take the opportunity to do what we can now with gdb.

It's true though that if we run ahead with our own DWARF formats while favoring GDB then the LLDB support will get worse. Perhaps we'll need to leave some option to stay LLDB compatible.

What's the advantage of providing our own version of GDB versus just relying on Rust support getting merged upstream eventually?

• We can turn on Rust-DWARF by default if we have confidence that all our users can read it. Otherwise we need to use C-compatible DWARF until we have confidence the Rust support has trickled out.
• Even once the Rust-DWARF support gets into the world, it will be very hard to evolve because of the lag time between us changing the definition, upstream landing, and upstream's downstreams distributing.

Can we provide an ergonomic enough experience for people to actually use this?

I'd expect we can do something where you type rust-gdb (or some new command), and it says "rust-gdb is not installed, run rustup component install rust-gdb", then you're ready.

How much maintenance effort would this mean?

For us it would mean updating the gdb build we produce at least once per quarter and remediating any issues that reveals.

And, more specifically regarding the co-evolution of DWARF and GDB, will we need a "debugger-tuning" flag in the compiler? (since, at least in the beginning, LLDB will still not know about Rust)

Yeah, seems like we would need to be able to emit at least two variations of DWARF. This would present some problems with the debuginfo in std.

This boils down to the questions if we can make something like rustup install rust-gdb just work on Linux and OSX and hopefully on Windows too, I think.

The quality of Windows support worries me too. It would be a shame if we couldn't support gdb there.

[brson]

My primary motivation for doing this is to be able to make more radical changes to our DWARF output. I'm only assuming that we need to make such changes, or have the resources to do it.

[tromey]

What's the advantage of providing our own version of GDB versus just relying on Rust support getting merged upstream eventually?

It's already merged.

And, more specifically regarding the co-evolution of DWARF and GDB, will we need a "debugger-tuning" flag in the compiler?

Probably not for gdb, but maybe for lldb.

My primary motivation for doing this is to be able to make more radical changes to our DWARF output. I'm only assuming that we need to make such changes, or have the resources to do it.

Yes, there's a need. There are a number of issues open about both errors in the generated debuginfo and also spots where more information is needed. Importing gdb into the tree isn't needed to make progress here (though you may want to do this for other reasons). I'm happy to write the gdb side upstream in parallel with rustc fixes.

The main issue I see is that there are few guards in place against rustc debuginfo regressions. 1.9 already regressed gdb's Rust support.

[Manishearth]

We could set up a build step that runs the gdb rust tests.

Build steps are straightforward and shouldn't take long:

• Ensure DejaGnu (runtest) is installed, built rustc is in the path
• Clone git://sourceware.org/git/binutils-gdb.git
• make all-gdb
• cd testsuite && make check RUNTESTFLAGS="gdb.rust/*.exp"

[Manishearth]

Alternatively we could get a gdb fork to use http://nightli.es/ with a rust-specific travis test

[vadimcn]

My primary motivation for doing this is to be able to make more radical changes to our DWARF output. I'm only assuming that we need to make such changes, or have the resources to do it.

Yes, there's a need. There are a number of issues open about both errors in the generated debuginfo and also spots where more information is needed.

Are these things spelled out anywhere?

[tromey]

Are these things spelled out anywhere?

Yes, I filed bugs for all the problems I found. Looking at open debuginfo bugs will show them all.

Looking at this, though, I see that the most important regression was closed (for some reason I thought the patch hadn't landed); so I'll have to re-test gdb with nightly and see if it's doing better now.

Some of the remaining holes require some work on DWARF or on detailing the Rust/DWARF binding. I've been planning to write a proposal for this, though I wasn't sure if this should just be a discourse post or a full-fledged RFC. Alternatively if someone gets to this before I do, I'd be happy to comment on it.

[tromey]

Still some failures with nightly -- better than 1.9, but 1.8 was clean. I'll diagnose soon, you can follow along here.