Repository navigation
ICE when trying to cross compile with xargo #47040
Description
I got an internal compiler error when trying to cross compile a project with the latest nightly using xargo.
% rustc --version :(
rustc 1.24.0-nightly (1abeb436d 2017-12-27)
% RUST_BACKTRACE=1 xargo build :(
Compiling water-sensor-firmware v0.1.9 (file:///home/rnestler/proggen/projects/coredump/water-sensor/water-sensor-firmware-rs)
error: internal compiler error: /checkout/src/librustc_metadata/cstore_impl.rs:131: get_optimized_mir: missing MIR for `DefId(7/0:8 ~ cortex_m_rt[efa4]::lang_items[0]::start[0])`
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.24.0-nightly (1abeb436d 2017-12-27) running on x86_64-unknown-linux-gnu
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'Box<Any>', /checkout/src/librustc_errors/lib.rs:504:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at /checkout/src/libstd/sys_common/backtrace.rs:68
at /checkout/src/libstd/sys_common/backtrace.rs:57
2: std::panicking::default_hook::{{closure}}
at /checkout/src/libstd/panicking.rs:381
3: std::panicking::default_hook
at /checkout/src/libstd/panicking.rs:391
4: std::panicking::rust_panic_with_hook
at /checkout/src/libstd/panicking.rs:577
5: std::panicking::begin_panic
6: rustc_errors::Handler::bug
7: <std::thread::local::LocalKey<T>>::with
8: rustc::ty::context::tls::with_opt
9: rustc::session::opt_span_bug_fmt
10: rustc::session::bug_fmt
11: rustc_metadata::cstore_impl::provide_extern::optimized_mir
12: rustc::ty::maps::<impl rustc::ty::maps::queries::optimized_mir<'tcx>>::compute_result
13: rustc::dep_graph::graph::DepGraph::with_task_impl
14: rustc_errors::Handler::track_diagnostics
15: rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::cycle_check
16: rustc::ty::maps::<impl rustc::ty::maps::queries::optimized_mir<'tcx>>::force
17: rustc::ty::maps::<impl rustc::ty::maps::queries::optimized_mir<'tcx>>::try_get
18: rustc::ty::maps::TyCtxtAt::optimized_mir
19: rustc::ty::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::instance_mir
20: rustc_mir::monomorphize::collector::collect_items_rec
21: rustc_mir::monomorphize::collector::collect_crate_mono_items
22: rustc::util::common::time
23: rustc_trans::base::collect_and_partition_translation_items
24: rustc::dep_graph::graph::DepGraph::with_task_impl
25: rustc_errors::Handler::track_diagnostics
26: rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::cycle_check
27: rustc::ty::maps::<impl rustc::ty::maps::queries::collect_and_partition_translation_items<'tcx>>::force
28: rustc::ty::maps::<impl rustc::ty::maps::queries::collect_and_partition_translation_items<'tcx>>::try_get
29: rustc::ty::maps::TyCtxtAt::collect_and_partition_translation_items
30: rustc::ty::maps::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::collect_and_partition_translation_items
31: rustc_trans::base::trans_crate
32: <rustc_trans::LlvmTransCrate as rustc_trans_utils::trans_crate::TransCrate>::trans_crate
33: rustc_driver::driver::phase_4_translate_to_llvm
34: rustc_driver::driver::compile_input::{{closure}}
35: <std::thread::local::LocalKey<T>>::with
36: <std::thread::local::LocalKey<T>>::with
37: rustc::ty::context::TyCtxt::create_and_enter
38: rustc_driver::driver::compile_input
39: rustc_driver::run_compiler
Reacted by Valentyn Valiaiev, Sanpi, LunNova, Danilo Bargen, ryochack and Hanno Braun
Activity
dcarosone commentedon Dec 29, 2017
Same here. First time trying to follow @japaric's cortex-m-quickstart instructions, using blue pill board support crate.
Only difference I can spot in the error or trace is the
[ca5c]which I assume isn't significantclebi commentedon Dec 29, 2017
Same here, trying to build for arm target using xargo.
japaric commentedon Dec 29, 2017
I think this is breakage caused by the new
Terminationtrait stuff (cf. #46479) and has nothing to do with Xargo.Minimal repro:
The error here is that the signature of the
startfunction has to change to include theTerminationtrait but the compiler is ICE-ing instead of showing a meaningful error. In general error messages related to lang items are not in good shape, due to them being unstable, and improving them is not a priority atm afaik.japaric commentedon Dec 29, 2017
Off-topic for the actual rustc issue but related to the sympton reported by the OP: The people that have been experiencing the ICE with the cortex-m-quickstart Cargo template and/or with the cortex-m-rt dependency should switch to version v0.3.8 of cortex-m-rt. The ICE should be gone when using that version. Calling
cargo updateorrm Cargo.lockshould do the trick.rnestler commentedon Dec 29, 2017
Hmm with the latest nightly and updated cortex-m-rt crate I get a segmentation fault from rustc! (In the LLVM parts, so I guess it's not Rusts fault 😉)
sfackler commentedon Dec 30, 2017
Segfaults inside of LLVM are actually often rustc's fault. It'll happen if you feed it invalid data and have it built with assertions disabled.
dcarosone commentedon Jan 2, 2018
With rustc 1.24.0-nightly (b65f0be 2018-01-01) I no longer get the segfault either
rnestler commentedon Jan 15, 2018
I still get a segfault with rustc 1.25.0-nightly (3f92e8d 2018-01-14)
canarysnort01 commentedon Feb 17, 2018
I encountered this problem in #48119. I worked around the LLVM assert by making my lang_start function signature match the one in the standard library (returns an isize not !), which is different than the example in RFC 1937.
camelid commentedon Oct 22, 2020
ping from triage: Status?
rnestler commentedon Jan 7, 2021
Well this is a pretty old bug and I'm not sure if it is worth to try and reproduce, since
xargoisn't actively developed anymore.Dylan-DPC commentedon Nov 1, 2022
Closing this as it is an old issue