Jonathan Pallant commented: https://gitlab.rtems.org/rtems/docs/rtems-docs/-/issues/32#note_112152 Hello, SPARC bare-metal target maintainer for rustc here. I only work on this in my free time, so apologies for the delay. It irked me that you were observing an issue that affected only CI builds of the Rust toolchain and not locally build copies, so I quite a bit of time into thinking about it. I've posted what I think is the solution to the Rust Zulip thread that was that opened, but I also wanted to address some points here, for the record. > Meanwhile, I contacted the maintainer of the Rust target > `sparc-unknown-none-elf` from Ferrous Systems. He has also no immediate idea > what happened. Only tier 1 targets are actively tested by the Rust community > and guaranteed to work. The SPARC target is tier 3. Yes, correct, although note that *I* volunteered to support this target, not my employer. > > Are there any other builds to do a binary search to narrow down when it > > broke? > For the nightly builds, I doubt there is any possibility to download old > builds for testing. Every nightly rust toolchain since 1.0 (or maybe before) is available in rustup. ```console root@f13ef12eb383:/# rustup toolchain install nightly-2015-05-16 info: syncing channel updates for 'nightly-2015-05-16-x86_64-unknown-linux-gnu' info: downloading component 'rust' 11.2 MiB / 103.3 MiB ( 11 %) 54.4 KiB/s in 21s ETA: 28m 53s^C ``` We also have https://github.com/rust-lang/cargo-bisect-rustc, which will automatically binary chop through nightly releases and find which release, and which commit within that release, broke your build. Anyway, having looked into it I'm pretty sure the answer is that your application ran out of stack. You don't observe this with a locally built compiler because you are electing to pre-build the libcore, so it is built with the release profile (and hence `-O2`). When you use nightly you are doing a source build of libcore, and so it follows whatever optimisations you have set for your project. As far as I can see, you have set none. There's also an additional gotcha here which is that you *only* compiled a local copy of rustc. When you did a `cargo +stage1 build` this used a *stable* copy of rustc (because that's better than complaining that you didn't build cargo), and so the unstable flag to enable building libcore from source was ignored. Try adding more stack space, or adding a stack canary to detect stack overflow, or use `--release` on your Rust builds - especially when building libcore from source. I suspect, but I have not tested (because I use macOS), that this will resolve your issue. -- View it on GitLab: https://gitlab.rtems.org/rtems/docs/rtems-docs/-/issues/32#note_112152 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
