libcore fails to compile for thumbv6m-none-eabi

[gnzlbg]

The libc crate cron job has started failing to build on master for the target thumbv6m-none-eabi. To reproduce:

cargo install xargo
rustup target add thumbv6m-none-eabi
git clone git@github.com:rust-lang/libc.git
cd libc
xargo +nightly build -vv --no-default-features --target thumbv6m-none-eabi

errors with

Compiling core v0.0.0 (/home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore)
     Running `rustc --edition=2018 --crate-name core /home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/lib.rs --color never --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C metadata=60fcc652106674f6 -C extra-filename=-60fcc652106674f6 --out-dir /tmp/xargo.t1IUdReqtxLM/target/thumbv6m-none-eabi/release/deps --target thumbv6m-none-eabi -L dependency=/tmp/xargo.t1IUdReqtxLM/target/thumbv6m-none-eabi/release/deps -L dependency=/tmp/xargo.t1IUdReqtxLM/target/release/deps --sysroot /home/travis/.xargo -Z force-unstable-if-unmarked`
warning: the feature `const_generics` is incomplete and may cause the compiler to crash
  --> /home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/lib.rs:77:37
   |
77 | #![cfg_attr(not(bootstrap), feature(const_generics))]
   |                                     ^^^^^^^^^^^^^^
LLVM ERROR: invalid symbol redefinition
error: Could not compile `core`.

libcore failing to build for the target is bad - that it prevents to build the libc crate for the target is a sideeffect of that.

[nikic]

I wasn't able to reproduce this based on your instructions. Though for me there is no attempt to even build core, it just builds libc.

[gnzlbg]

Though for me there is no attempt to even build core, it just builds libc.

Weird. The first thing xargo does is build a sysroot for the target, and the first step of doing that is building libcore.

[gnzlbg]

See the exact build failure in libc's CI which mentions the exact same xargo invocation and how the first thing xargo does is building libcore: https://travis-ci.com/rust-lang/libc/jobs/219031083#L5403

[nikic]

I suspect that it doesn't build libcore because it's already distributed by rustup (and removing the rustup target makes compilation fail with libcore not found). Maybe something needs to be done to force building of libcore even for a non-custom target?

[gnzlbg]

I don't really follow. xargo and cargo-xbuild ignore anything distributed by rustup, except for the rust-src component, which include libcore sources, and as can be seen in the logs, the first thing they do is compiling the core crate, which fails with an LLVM error since the LLVM upgrade.

[gnzlbg]

AFAIK, we do not ship a rust-std component for this particular target.

[jonas-schievink]

thumbv6m-none-eabi has a rust-std component that contains just libcore (it's the only target we ship that works on Cortex-M0 chips, so it's quite important for embedded)

[nikomatsakis]

@gnzlbg can you try to bisect the regression -- ideally to a specific PR? The https://github.com/rust-lang-nursery/cargo-bisect-rustc tool may be of use! I'm marking this as P-high so that we check in on it but it seems like it's not yet clear whether this is a compiler bug exactly or what.

[gnzlbg]

I think it would be helpful if somebody else can reproduce this issue first. Following the instructions that I posted in the OP, I can reproduce this both on a x86_64-unknown-linux-gnu and a x86_64-apple-darwin host, with the current nightly (rustc 1.38.0-nightly (03f19f7 2019-07-24)).

@nikic which host are you on ?

[gnzlbg]

@nikomatsakis PR wise we started seeing this right after #62592 was merged. I'm afraid that on my home laptop compiling rustc twice to test will take me... days.

[nikic]

@gnzlbg I was able to reproduce after doing a rustup default nightly. I'm not sure why that works while xargo +nightly doesn't. Now I get the LLVM error.

[jonas-schievink]

Ah, indeed! rustup override add nightly makes the error appear.

[gnzlbg]

I'm not sure why that works while xargo +nightly doesn't.

So I do indeed have nightly as my default Rust toolchain, and on libc's CI this is the case as well for that build job. I'll report this to xargo upstream.

[nikic]

There's a couple of places that can throw this error, the one we hit is https://github.com/llvm/llvm-project/blob/930df11a0d00c467b17c76f2b782a96bf721599b/llvm/lib/MC/MCStreamer.cpp#L354-L355.

The symbol in question is .LJTI27_0, a jump-table label.

[nikic]

Finally managed to get a reproducer (turns out this only crashes llc at -O3): https://gist.github.com/nikic/1fa40bc972e815f9606518c5b2218699

[nikic]

I've opened an LLVM bug at https://bugs.llvm.org/show_bug.cgi?id=42760.

[gnzlbg]

FYI rust-lang/stdarch game boy advance build job is affected by this as well.

[nikic]

Fixed upstream in llvm/llvm-project@4f8259b and backported to LLVM 9 in llvm/llvm-project@4e21661.

LLVM submodule update pending in #63302.