Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Distribute both rust-lldb and rust-gdb everywhere #32835

Merged
merged 1 commit into from
May 6, 2016

Conversation

brson
Copy link
Contributor

@brson brson commented Apr 8, 2016

Both debuggers are viable in some capacity on all tier-1 platforms,
and people often ask for rust-lldb on Linux or rust-gdb on OS X.

r? @michaelwoerister

I'm still testing locally, but this looks like the right thing to change.

@brson
Copy link
Contributor Author

brson commented Apr 8, 2016

This probably also needs to be changed in rustbuild... cc @alexcrichton

@brson brson force-pushed the alldebug branch 2 times, most recently from 2bd83df to be736f9 Compare April 8, 2016 19:18
@brson
Copy link
Contributor Author

brson commented Apr 8, 2016

(rustup and multirust both install the proxies on all platforms)

@michaelwoerister
Copy link
Member

The problem with this so far is that LLDB doesn't work all that well on Linux for Rust programs (at least the last time I checked) and the pre-installed version of GDB on OSX is very old and probably doesn't really support our pretty printers. I don't want to give the impression that we expect these combinations to work well out of the box.

As a side note: In principle LLDB should work just fine on Linux. We just might have to tweak some small things in the DWARF we emit.

@michaelwoerister
Copy link
Member

@brson If we decide to do this, we should also clean up the now unneeded targets in debuggers.mk

@alexcrichton
Copy link
Member

rustbuild changes look good to me at least

@brson
Copy link
Contributor Author

brson commented Apr 8, 2016

Just an idea: we could also distribute a script called rust-dbg that is the script we recommend people use for debugging, and have it default to the tool we suspect works best, with flags to use the other.

@michaelwoerister
Copy link
Member

I'd be up for that. With 'also' you mean in addition to the existing ones?

@alexcrichton
Copy link
Member

That sounds plausible to me, yeah.

One part I also just remembered is that we probably don't want to distribute shell scripts on Windows as they only work in the MSYS shell, not anything else. We may want to just compile dedicated binaries perhaps?

@retep998
Copy link
Member

retep998 commented Apr 8, 2016

The correlation between users of msys and users of gdb/lldb is extremely high on Windows anyway, so I wouldn't be worried about providing those shell scripts with the -gnu distribution. Just don't include them with -msvc as anyone using that will be using VS as their debugger.

@bors
Copy link
Contributor

bors commented Apr 19, 2016

☔ The latest upstream changes (presumably #32755) made this pull request unmergeable. Please resolve the merge conflicts.

@brson
Copy link
Contributor Author

brson commented Apr 28, 2016

I've updated this to distribute rust-lldb and rust-gdb everywhere except windows-msvc.

I'm having second thoughts about adding rust-dbg. Adding a new executable is a big deal, and this one would have fairly slight value.

Maybe there are other things we could do to guide people to the right one.

Another option would be to make both of them rust-installer components, and make them optional on their 'bad' platforms so they wouldn't be installed by default. If we were to go that route though we should seriously consider converting them to cargo packages.

@brson
Copy link
Contributor Author

brson commented Apr 28, 2016

cc @rust-lang/tools Trying to decide how to make both the rust-lldb / rust-gdb wrappers available to everyone while encourage lldb on os x and gdb on other unixes. I've proposed several things: adding a new rust-dbg wrapper that does the preferred thing; or converting both to a package that can be installed or not independently.

@michaelwoerister
Copy link
Member

This might be interesting: I've been tinkering with LLDB on Linux while trying to resolve some issues regarding newer LLDB versions, and it seems that LLDB is starting to become rather stable there. Though one problem currently is that only the "nightly" version will work at the moment, because it contains a patch to make it handle Rust programs again.

@nrc
Copy link
Member

nrc commented Apr 28, 2016

Just an idea: we could also distribute a script called rust-dbg

I'm in favour of this, I find it awkward explaining to people about the debug scripts, and just having one would make it much easier (don't have to ask what platform they're on, etc.)

I think it will be some time before we can really recommend lldb on Linux, especially since the Rust-specific stuff just landed in GDB.

@michaelwoerister
Copy link
Member

I think it will be some time before we can really recommend lldb on Linux

I wouldn't recommend it either. But distributing the rust-lldb script there seems viable to me now.

@nrc
Copy link
Member

nrc commented Apr 28, 2016

But distributing the rust-lldb script there seems viable to me now.

agreed

@vadimcn
Copy link
Contributor

vadimcn commented Apr 28, 2016

👎 on rust-dbg: lldb and gdb use quite different sets of commands, so it'll just add to confusion. The user will be able to launch a debugger, but what then? You need to know which one it is to do anything.

@alexcrichton
Copy link
Member

I agree with @vadimcn and the hesitation to ship rust-dbg, but I also like shipping rust-{gdb,lldb} everywhere other than MSVC by default.

@dlrobertson
Copy link
Contributor

Agreed, I like shipping both but no rust-dbg.

I think it will be some time before we can really recommend lldb on Linux, especially since the Rust-specific stuff just landed in GDB.

I think some documentation specifying this would be enough. Then again, I could be wrong... I'm still very much a noobie 😄

@brson
Copy link
Contributor Author

brson commented May 6, 2016

@michaelwoerister Let's just do it.

There does seem to be a build failure though.

@brson
Copy link
Contributor Author

brson commented May 6, 2016

I pushed an update that should fix build error, caused by debugger_pretty_printers_common.py being copied twice.

@brson
Copy link
Contributor Author

brson commented May 6, 2016

One simple thing we could do is platform detection in rust-lldb/rust-gdb and warn on the lesser platform.

Both debuggers are viable in some capacity on all tier-1 platforms,
and people often ask for rust-lldb on Linux or rust-gdb on OS X.
@michaelwoerister
Copy link
Member

@bors r+

We (or I) might just be overthinking this/be to careful. People will generally know which debugger works best on which platform. Let's not annoy them with warnings.

@bors
Copy link
Contributor

bors commented May 6, 2016

📌 Commit 5ad99e2 has been approved by michaelwoerister

@bors
Copy link
Contributor

bors commented May 6, 2016

⌛ Testing commit 5ad99e2 with merge 68d399d...

bors added a commit that referenced this pull request May 6, 2016
Distribute both rust-lldb and rust-gdb everywhere

Both debuggers are viable in some capacity on all tier-1 platforms,
and people often ask for rust-lldb on Linux or rust-gdb on OS X.

r? @michaelwoerister

I'm still testing locally, but this *looks* like the right thing to change.
@bors bors merged commit 5ad99e2 into rust-lang:master May 6, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants