Package gdb with Rust #34457
Comments
|
Sounds great to me, I'm all for it! |
|
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:
|
|
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). |
|
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. |
|
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:
Here are some thoughts, but I'd also like to hear how other people would answer these questions:
So, I think, I'm generally in favor of this if we can pull it off with reasonable effort. |
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.
I'd expect we can do something where you type
For us it would mean updating the gdb build we produce at least once per quarter and remediating any issues that reveals.
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.
The quality of Windows support worries me too. It would be a shame if we couldn't support gdb there. |
|
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. |
It's already merged.
Probably not for gdb, but maybe for lldb.
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. |
|
We could set up a build step that runs the gdb rust tests. Build steps are straightforward and shouldn't take long:
|
|
Alternatively we could get a gdb fork to use http://nightli.es/ with a rust-specific travis test |
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. |
|
Still some failures with nightly -- better than 1.9, but 1.8 was clean. I'll diagnose soon, you can follow along here. |
|
The methods failures are due to |
That is a problem. Can we somehow provide two versions of the debuginfo and make the wrapper scripts add the right one to the search path?
That's a good point. We definitely would have to include the Rust version of GDB into autotests. But that's also something that should actually become easier if we distribute our own version, right?
I absolutely agree with @tromey. We are basically stuck if we don't co-evolve the compiler and debuginfo consumers.
@tromey I'd be interested in this too. What would be the best place to allow multiple people working on it? |
|
BTW, there might be a pretty big shift in the way LLVM handles debuginfo: TL;DR; DWARF or any other debuginfo might be emitted directly to LLVM IR instead of as LLVM metadata. The good thing about that is that we would have total control about what we emit and would not have to rely on LLVM merging any custom |
|
I'm in favour of doing this. I think lowering the bar for getting good debugger support for Rust on at least one platform is very worthwhile. There is too much friction right now for a user to get to a good debugging experience. My major worry is that we don't have the long term resources to keep this in a good place. Debuginfo in the compiler is already under-resourced and slowly bit-rotting, I fear that our gdb fork would end up in the same place, or worse. |
|
The gdb fork probably won't stay a fork, patches will keep getting upstreamed. We just maintain a fork so that we can iterate faster, and the only commits that live in the fork would be things like this special function (which could also live in rust-gdb) On the note of rust-gdb, what is the proposed future for rust-gdb? I left a comment here, but that seems to be something better discussed in this thread. |
I have been working on a google doc. Contact me in email and I'll share it with you. It's not nearly done yet. |
|
One issue with packaging GDB for macOS is that the binary needs to be codesigned in order to function. |
|
The tools team discussed this issue during triage yesterday and the main conclusion was that we're probably not quite in a position just yet to actively ship gdb. That being said, we're very willing to actively test newer versions of gdb to ensure that our support does not regress. In other words, we're always willing to have more automation! The major blockers we think need to be overcome before making progress on this are:
|
|
Do we need to worry about man-in-the-middle attacks on the insecure |
|
Presumably we'd have a fork on github, so no. |
|
@Manishearth how will that fork be cloned/updated? |
|
There are two of us with access to ssh gdb sources. Though this is a very narrow threat model which I don't expect to happen, really. |
|
Update: HTTPS access to GDB was broken due to a bug; this has now been fixed (at least I managed to check out the sources). |
|
I'm trying to debug on Windows and I still can't do it well. TDM GDB sort of works in VSCode but step debugging is broken. At this point its easier to debug code by plastering logging all over the place and trying to pinpoint the issue. I think shipping gdb with the stable-gcc would take a lot of guesswork out of making it work. TDM's gdb standalone is a 12MB zip so that's we're talking about sizewise |
Mark-Simulacrum
added
T-dev-tools
Mark-Simulacrum
added
C-feature-request
|
As part of my work on the Rust language plugin, I talked about shipping the plugin on the upstream list. There are two threads:
My conclusion from all of this is that we'll need some way to ship some lldb-related thing via rustup. In the short- and medium-term, this is likely to be all of lldb. In the longer term, maybe we can either ship just the Rust plugin (if lldb ever provides a way to build a language plugin out-of-tree), or just the Rust expression parser helper library/executable. |
|
I've come around on this and I think it would make sense to get gdb into rustup. This would let us ship Rust improvements more quickly to users. The main issues are around library dependencies. There's some discussion in #48168. There may also be some path issues, like finding system separate debuginfo or system gdb scripts. |
|
I'm looking into this a bit. A couple possible issues:
|
I think a runtime wrapper will be better - especially if/when we move rustup into Cargo, we won't want to support that kind of check (although there are also vague plans for things like post-install scripts which could do this). cc @joshtriplett for any potential distro interactions. |
This optionally adds gdb to the Rust build, allowing gdb to be installed via rustup. This makes it simpler to make debuginfo changes, as gdb updates can now be shipped immediately. If gdb is not checked out, nothing changes. The build is perhaps a bit chatty, as gdb's "make" and "make install" are run each time, even if they do nothing. rust-gdb is modified to prefer the gdb installed by rustup. This is analogous to what was done for rust-lldb. The built gdb requires Python 2.7 as a shared library (other dependencies are statically linked). This is a least-common-denominator Python that is widely available and stable; dynamic linking is used to avoid breaking existing gdb Python code that might load shared libraries that themselves require a dynamic libpython. To avoid problems here, a small wrapper program is used that attemps to dlopen libpython; with failures being reported to the user in an intelligible way. Two of the Linux dist builds are updated to build gdb. More could be added if need be. If gdb is built as part of the build, and if no other gdb was specified in config.toml, then the just-built gdb will be used for debuginfo testing. Closes rust-lang#34457
Add gdb to the build This optionally adds gdb to the Rust build, allowing gdb to be installed via rustup. This makes it simpler to make debuginfo changes, as gdb updates can now be shipped immediately. If gdb is not checked out, nothing changes. The build is perhaps a bit chatty, as gdb's "make" and "make install" are run each time, even if they do nothing. rust-gdb is modified to prefer the gdb installed by rustup. This is analogous to what was done for rust-lldb. The built gdb requires Python 2.7 as a shared library (other dependencies are statically linked). This is a least-common-denominator Python that is widely available and stable; dynamic linking is used to avoid breaking existing gdb Python code that might load shared libraries that themselves require a dynamic libpython. To avoid problems here, a small wrapper program is used that attemps to dlopen libpython; with failures being reported to the user in an intelligible way. Two of the Linux dist builds are updated to build gdb. More could be added if need be. If gdb is built as part of the build, and if no other gdb was specified in config.toml, then the just-built gdb will be used for debuginfo testing. Closes #34457
|
Some state here: The PR may not be merged, as it puts gdb into the overall rust build; and this build is already quite slow, etc. Instead Alex said he'd be investigating whether gdb could be built separately and then the artifacts still distributed via rustup. This would definitely be nicer. The PR is still of use though. It shows how to make a Dockerfile that installs the needed static dependencies. And, it patches the There's a fork of gdb here: https://github.com/rust-dev-tools/gdb. My plan for this was to treat it like we do LLVM: keep some Rust-specific patches here (e.g., there is one to deal with the Python issue there), but otherwise keep it close to upstream. In particular, anything that would be generically useful should go upstream first, with the only divergences being things needed for the peculiarities of rustup and/or the build setup. |
|
ping! It's 2020, do you know where your civilization is? This issue was opened with the assertion that "gdb has first-class support for Rust now, and two active maintainers (@tromey @Manishearth). Let's package it with Rust." Is this still true? Per rust-lang/rustup#2532, it seems we currently ship a rust-gdb wrapper in Rustup, but it needs documentation. This is especially confusing to me because unlike most optional pieces of Rust, it isn't in rustup's component list, and I actually don't have gdb installed so it errors to invoke it. |
|
I don't know about tromey, but I'm not actively maintaining it (though if notified of bugs i would try to fix it). The gdb community seems to be maintaining it just fine though. There are no active plans to package it with rust given that nobody is working on evolving rust DWARF right now and gdb support has baked for a couple years (and is present on most distribution venues). This issue still has value in being open if we want to do this in the future. We could close it in the meantime, idk. rust-gdb is a wrapper that sets up python pretty printers, and has existed for a really long time (before there was gdb support or even rustup). It's not clear to me if pretty printers are still necessary given the first class support, so it's worth evaluating what it does that gdb doesn't, filing gdb bugs for that behavior if possible, and getting rid of it. Some people may still use it though, so we should be careful. TLDR it's a legacy tool that may still have use cases but as a legacy tool it's underdocumented. If folks want to work on figuring that out -- either documenting it or evaluating if it can be removed, that would be great! |
|
@Manishearth Who can I ping to update https://rustc-dev-guide.rust-lang.org/debugging-support-in-rustc.html based on your info? |
|
@sanmai-NL the rustc dev guide is a repo under the rust GitHub org, you can make PRs to it |
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:
Steps:
cc @michaelwoerister @rust-lang/tools What you think?
The text was updated successfully, but these errors were encountered: