rust 1.77.1 fails to build natively on armv7-unknown-netbsd-eabihf #123549
Comments
rustbot
added
the
needs-triage
|
That aarch64 stack overflow I mentioned above is now reported in #123551. |
jieyouxu
added
O-Arm
Given that this is in Rust, it is not at all boring... it seems very unlikely to be a bug in the crashing part of the compiler, this is probably a miscompilation. |
Noratrieb
added
I-unsound
rustbot
added
the
I-prioritize
Maybe. But ... if this is a code generation bug, is anything similar observed on other armv7 platforms? I on my side will re-try the build with an exteral LLVM, version 16.0.6, instead of the embedded 17.0.6 version, though that will require an LLVM rebuild, so will take a while to complete. Will return with status when that's done. |
|
people generally don't compile rustc on armv7 platforms (it's a pretty weird thing to do imo, especially as it does take so long, cross compilation is a thing) so I wouldn't be too surprised if no one has hit this |
|
Hm, yes, I'm not surprised. However, self-building rust turns out to be an effective "stress test" of the compiler. Wrt. the included LLVM: rust 1.76.0 contains the same version of LLVM (17.0.6) as rust 1.77.1, so ... this makes it slightly dubious whether replacing the embedded LLVM with an external one will fix this problem. :( |
|
If you could bisect it down that would be great... and take quite a while though.. so not exactly ideal either. 🙃 |
|
Bisecting will be troublesome at best, since my build setup is based on rust tarballs and not github checkouts. Though I'm receptive to hints on how to do that. No promises, though... |
|
Just checking: the title of this issue, and OP, both mention "1.71.1", but I presume they are typos for "1.77.1"? |
saethlin
changed the title
Yes. How sloppy of me. I see that's fixed. |
What about using |
I don't think that will do the same -- won't that leave out all the vendored crates? |
|
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-low |
rustbot
added
P-low
apiraino
added
the
regression-from-stable-to-stable
|
FWIW, I did a re-try where I configured rust to use an external LLVM (version 16.0.6), and perhaps unsurprisingly, this didn't fix the issue -- the stage-2 rust compiler still gets a SEGV compiling the same code (though I didn't do GDB this time). So this is an indication that this is probably a bug in the part of the compiler written in rust. "How fun." |
Yes, I do realize that cross compilation is a thing. However, one must have some assurance that the cross-compilation produces correct results. So in the mean time I have tried using the cross-built rust compiler (built on NetBSD/amd64, targeting NetBSD/armv7) to natively build the So... This has me asking what the state is for testing the results of cross compilation from other systems targeting armv7? The above test should at least be fairly easy to carry out on other armv7 systems. |
|
I have re-tried this with rust 1.78.0 which brings along a new major version of the embedded LLVM, and the status is basically the same as reported above. I'm also building rust for among others amd64, riscv64, sparc64, 32-bit powerpc, all on NetBSD, and none of these behave this way. I'm therefore left wondering if there is something CPU-specific for armv7 which should be done on NetBSD, which is new in 1.77.*, and which currently isn't there. Parts of my summarized test results is as follows, all on NetBSD, and "success" is gauged by the platform self-hosting the rust compiler and being able to build This indicates that what I'm seeing is not an "OS error", probably not an artifact of my build setup (since it successfully cross-compiles for other CPUs / targets, and earlier versions have produced working results for armv7), and is probably CPU-dependent, perhaps coupled with the particular OS I'm building for. |
|
Hmm, I guess #122002 doesn't fix it either. |
|
It is likely the fix is to disable the |
While working through the testing of rust 1.77.1 for the various NetBSD targets we try to keep rust running on, I am having trouble getting rust to build "natively" on an emulated armv7 system.
I expected to see this happen: The build of rust should complete.
Instead, this happened: Rust 1.77.1 fails to build, while the build of 1.76.0 succeeded.
The error I see is a SIGSEGV error in the rust build, using the
stage2rust compiler, which is built with the embedded LLVM in the rust distribution, either when building thelibccrate, or sometimes (I tried restarting the build multiple times) when building theproc-macro2orunicode-identvendor crates.I initially tried running the build with a parallelism of 3, but have dialed that down to 1 now to eliminate any issues with that and also to make the build log less confusing, and it now looks like it has consistent problems building the
libc-v0.2.151crate. This happens quite a bit into the build, initially after 40+ hours, and as mentioned, while using thestage2compiler, so this is rustc 1.77.1 itself. I initially had problems getting any information out of this from gdb, but this now succeeded, hence this problem report. The end of the build log was in this latest rebuild attempt:and the corresponding
gdbsession looks like it actually managed to pick the appropriate information out of the system:So ... this looks at least on the surface of it like a "boring" NULL pointer de-reference.
However, I am also having issues building rust 1.71.1 natively on arm64 (not yet reported), and on that platform a stack overflow is flagged, so I wonder if this could be the same problem. The stack in the above backtrace is kind of long...
Meta
rustc --version --verbose:Backtrace
See above.
The text was updated successfully, but these errors were encountered: