Ship a custom LLDB with Rust support

[alexcrichton]

I hear that @tromey has been doing some awesome work with Rust-specific support in LLDB, and we should enable easily shipping that work to users! This is intended to be a checklist/tracking issue of sorts of the work needed to be done to enable this.

• One of the first things we'll need to do is to add it to the Rust source tree (off by default). This will probably involve adding a submodule and adding rustbuild logic to build LLDB. This will currently, as of this writing, require syncing the LLDB work to get based off the same LLVM version we have in tree, presently the release_60 branch.
• Next up we'll want to confirm that LLDB works with sccache and is being cached properly when using sccache. The change here would basically be ensuring that --enable-ccache works for LLDB locally.
• After that we'll want to build LLDB on the dist bots, but not upload it yet. This'll help us evaluate impacts on cycle time, if any. The change here should mostly just be tweaking flags in travis/appveyor/dockerfiles
• Next we'd add rustbuild support for creating a new LLDB component that we'd publish on the dist bots. This would probably look similar to the support for RLS (ish).
• And finally we'd teach rustup.rs about the LLDB component, allowing rustup component add lldb (or whatever the name is), but this is much farther down the line!

[michaelwoerister]

cc me

[tromey]

#52716

[tromey]

The first item is done. I'm testing the second item now. I had thought that the third item would be covered by the .travis.yml change in the patch for the first item -- is that not so? I think the rustbuild bits are done too (?). I haven't looked into rustup.rs yet.

[alexcrichton]

@tromey I think we'll need to wait for a new nightly to see whether or not rustup works, at that point we should have a look at the manifest and it ay already work!

[tromey]

Thanks. Also, a local --enable-ccache build worked fine.

[michaelwoerister]

@tromey, I saw that dynamically linking to LLVM is disabled when shipping LLDB:

rust/src/bootstrap/native.rs

Line 175 in 142bb27

!want_lldb {

Is that a hard requirement? Because we might want to enable dynamic linking when compiling LLVM with ThinLTO (see #53245).

[tromey]

Is that a hard requirement?

I don't think so.

[tromey]

This reports that it didn't work: https://internals.rust-lang.org/t/rust-debugging-quest/6753/13?u=tromey

I haven't looked into it yet.

[tromey]

lldb isn't mentioned in channel-rust-nightly.toml, which I guess it should be. I don't know how this is made.

[cynecx]

@tromey I am not familiar with the code but if I follow the code correctly, there might be an issue here:

rust/src/tools/build-manifest/src/main.rs

Lines 461 to 467 in afd0a2f

	let version = match *self.cached_version(pkgname) {
	Some(ref version) => version.clone(),
	None => {
	println!("Skipping package {}", pkgname);
	return;
	}
	};

cached_version(...) is called with "lldb-preview":

rust/src/tools/build-manifest/src/main.rs

Lines 534 to 535 in afd0a2f

	} else if component == "lldb" || component == "lldb-preview" {
	&self.lldb_version

lldb_version is initialized here:

rust/src/tools/build-manifest/src/main.rs

Line 276 in afd0a2f

self.lldb_version = self.version("lldb", "x86_64-unknown-linux-gnu");

So I think the problem here is that call to version with x86_64-unknown-linux-gnu as target, it basically tries to extract the version of that particular target archive. And according to #52716, lldb is only built for macOS on nightly. Therefore the call version returns None and lldb_version is then None.

[tromey]

Thanks for your note. That's a good find!