Skip to content
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

SIGSEGV when trying to link with nostartfiles flag #361

Closed
nikarul opened this issue May 31, 2020 · 8 comments
Closed

SIGSEGV when trying to link with nostartfiles flag #361

nikarul opened this issue May 31, 2020 · 8 comments

Comments

@nikarul
Copy link

nikarul commented May 31, 2020

I'm getting a SIGSEGV error when I try to build a project that depends on compiler-builtins, when passing the nostartfiles flag to the linker. I can also reproduce this in the git master branch of compiler-builtins with the .cargo/config file below:

Compiling compiler_builtins v0.1.31 (/work/compiler-builtins)
error: failed to run custom build command for `compiler_builtins v0.1.31 (/work/compiler-builtins)`

Caused by:
  process didn't exit successfully: `/work/compiler-builtins/target/debug/build/compiler_builtins-f9b68c234adcc015/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)

.cargo/config:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "link-arg=-nostartfiles"]

Rust version: rustc 1.45.0-nightly (74e804683 2020-05-30)

It seems similar to issue #338, but that seems like it may have been already addressed back in rust 1.41, given info in the linked Rust bug.

@bjorn3
Copy link
Member

bjorn3 commented May 31, 2020

In this case the build script crashes and not rustc. Can you get a backtrace for the crash?

@nikarul
Copy link
Author

nikarul commented Jun 1, 2020

Not really. GDB gives me this:

$ gdb /work/compiler-builtins/target/debug/build/compiler_builtins-f9b68c234adcc015/build-script-build
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /work/compiler-builtins/target/debug/build/compiler_builtins-f9b68c234adcc015/build-script-build...
(gdb) r
Starting program: /work/compiler-builtins/target/debug/build/compiler_builtins-f9b68c234adcc015/build-script-build 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000001 in ?? ()
(gdb) bt
#0  0x0000000000000001 in ?? ()
#1  0x00007fffffffe64d in ?? ()
#2  0x0000000000000000 in ?? ()
(gdb)

I tried on a couple machines, made sure I had glibc debug symbols installed, but no luck. Looks like the stack is completely trashed. And there's no symbols for build-script-build, so I can't break anywhere useful, either.

@iwanders
Copy link

Hi, I ran into this myself, took some time, but I figured out why this happens and found a solution that resolved the situation for me.

In my situation, I have rustflags = "-C link-arg=-nostartfiles" in .cargo/config.toml as well, inspecting the build plan (printed with cargo b -Z unstable-options --build-plan) showed that when building with cargo build, this flag is also passed to the build.rs script that's in the root of this crate. After the build script is compiled it is ran, but if -nostartfiles is passed to it, this fails with the segfault seen above, I also tried to get symbols for that backtrace, but that proved futile. So, issue is that -nostartfiles is passed to the compilation of the build script. In that sense, it has nothing to do with this crate, I think this would apply to all build scripts (but guess this flag is more common for users of this crate). I tried manually calling the different build steps from the build plan, leaving out the -nostartfiles on the build script, and that all worked and made the binary I wanted.

I found rust-lang/cargo#9453, which specifically details the feature we need in this case, we do want to pass this flag to the target, but not to any build scripts because they just won't run with this flag. This rust-lang/cargo#9634 PR and rust-lang/cargo#9753 this one have some more details around it all. As far as I understand it, there currently is a difference between cargo build and cargo build --target x86_64-unknown-linux-gnu (even when the host itself is on x86_64-unknown-linux-gnu). In the former case, the build flags are applied to the build.rs scripts, in the latter they are not.

TL;DR: Build with the target specified on the command line; cargo build --target x86_64-unknown-linux-gnu if you are using -nostartfiles to ensure the build script can be ran successfully.

@jameshilliard
Copy link

Does setting these env varibles fix it?

__CARGO_TEST_CHANNEL_OVERRIDE_DO_NOT_USE_THIS="nightly"
CARGO_UNSTABLE_TARGET_APPLIES_TO_HOST="true"
CARGO_TARGET_APPLIES_TO_HOST="false"

@iwanders
Copy link

That doesn't resolve the issue. The build-plan output shows the link-arg=-nostartfiles is still being passed to the build script.

@jameshilliard
Copy link

Oh, minimum stable version for this to work should be 1.54.0, what version are you on?

@iwanders
Copy link

I'm on yesterday's nightly (8cdb3cd94 2022-01-25). I've pushed the minimal-not-working example I have to this branch, the test.sh is what I used to test the flags proposed. I may have just missed a config flag in setting up the target-applies-to-host functionality. I expect you can reproduce the failure locally, I'm on a x86_64-unknown-linux-gnu platform.

@Amanieu
Copy link
Member

Amanieu commented Jan 26, 2022

This is an issue in cargo and not compiler-builtins, you should open an issue there.

@Amanieu Amanieu closed this as completed Jan 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants