-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error with -C code-model=large and thread locals #37508
Comments
Compiling mini.rs statically (with glibc, as described at https://github.com/aidanhs/rustnotes) makes it not segfault, which is interesting. Doing --enable-debug in configure also makes it not segfault. I starting to suspect the issue is in llvm (I don't think anything in the rust compiler itself generates asm?) and rust tickles the bug somehow. |
Recompiling just the libstd crate without optimisations makes it work. It appears that
By inspection of the parameters passed to |
Managed to tear down std to get this test case:
(it seems that since I originally reported this issue, the nightlies now have llvm assertions enabled) |
Abort seems to be coming from TwoAddressInstructionPass. Backtrace (from gdb) at the point of abort is: Click to expand backtrace
|
The rust code two comments up (#37508 (comment)) when compiled with
If you now try and compile this with
It works fine on the latest LLVM head. Turns out the fix was merged december 7th - https://llvm.org/bugs/show_bug.cgi?id=31271 is the bug, https://reviews.llvm.org/D27481 is the fix. |
Looking at the llvm 4 release branch on the llvm-mirror github, this will be fixed when rust upgrades - #37609. |
I backported the referenced patch, built a debug rust with it (i.e. debug-rust-large-fixed) and then built a release mode rust also with the backported patch and debug-rust-large-fixed (which took forever) and successfully ended up with a release-rust-large-fixed which can build itself. |
Presumably fixed by LLVM backport -- doesn't reproduce today. I'm marking as E-needstest since it seems like something we should track in tests. |
@Mark-Simulacrum fwiw this is tricky to do a test for unless we want to do yet another rustc build in CI. I'm going to be rebasing our Rust fork 'shortly' and was planning to just close this issue once that's done and I've verified everything is working. |
Oh... do we need to rebuild rustc for it? I was under the impression that just |
Urgh yes. Sorry, this issue has a lot of history for me and I'd forgotten parts of it. Running the |
Add tests for a few issues. Fixes rust-lang#41998 Fixes rust-lang#38381 Fixes rust-lang#37515 Fixes rust-lang#37510 Fixes rust-lang#37508 Fixes rust-lang#37366 Fixes rust-lang#37323 Fixes rust-lang#37051 Fixes rust-lang#36839 Fixes rust-lang#35570 Fixes rust-lang#34373 Fixes rust-lang#34222 Certainly not all of the E-needstest issues right now, but I started to get bored.
Triage: apparently #42724 added a test, but it was removed before it was merged. |
…-37508, r=Mark-Simulacrum Add test for thread-local and code-model=large Closes rust-lang#37508
…-37508, r=Mark-Simulacrum Add test for thread-local and code-model=large Closes rust-lang#37508
…ark-Simulacrum Add regression test for issue rust-lang#37508 Add regression test for issue rust-lang#37508 Closes rust-lang#37508 Took this test from rust-lang#37508 and updated the panic handler to the modern standard. r? `@Mark-Simulacrum` Mark, I hope you don't me tagging you here. You were involved in the original issue and I hope you might be more comfortable reviewing this.
(allowing specifying code models was added to rustc in #15698)
I want to build a large code model binary. But (correct me if I'm wrong) I believe this requires all code to be generated with a large code model (otherwise we could end up with rip relative addressing in the stdlib, which defeats the point).
So I tried the obvious (controlling it with
RUSTFLAGS
) and got the following build log:Brief explanation of the three parts:
In fact, this stage1 rustc segfaults when not doing much:
Reducing the command line used to build rustc:
GDB gives the backtrace as
I've dumped a bunch of info in the hope that someone might be able to lend a hand, but I can find little discussion of this feature (code models) so they may not be well-tested? I plan to investigate myself, but wanted a) to see if anyone has any pointers and b) make this a searchable issue.
As a datapoint, note that redox uses a .json target specification and builds its own stdlib manually with kernel model, which obviously works fine. Altering the configure+make command I used to use the kernel model rather than large also worked fine. So it looks like the issue is with memory model large.
The text was updated successfully, but these errors were encountered: