segfault running debug static musl hello world app on Linux

[lukebond]

I'm trying to build a static binary of a Rust application on Linux and it segfaults, so I created a smaller test case.

Here is my main.rs file:

fn main() {
    println!("Hello World!");
}

I ran the following:

$ rustup target add x86_64-unknown-linux-musl
$ cargo init
$ TARGET_CC=musl-gcc RUSTFLAGS="-Ctarget-feature=+crt-static" cargo build --target=x86_64-unknown-linux-musl
   Compiling helloworld v0.1.0 (/home/luke/Development/helloworld)
    Finished dev [unoptimized + debuginfo] target(s) in 0.19s
$ file target/x86_64-unknown-linux-musl/debug/helloworld
target/x86_64-unknown-linux-musl/debug/helloworld: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, with debug_info, not stripped
$ ldd target/x86_64-unknown-linux-musl/debug/helloworld
	statically linked
$ ./target/x86_64-unknown-linux-musl/debug/helloworld
Segmentation fault (core dumped)

I had previously installed musl-gcc on my system using the Arch package manager:

$ pacman -Qo /usr/bin/musl-gcc
/usr/bin/musl-gcc is owned by musl 1.2.2-1

If I make a release build, it doesn't segfault:

$ TARGET_CC=musl-gcc RUSTFLAGS="-Ctarget-feature=+crt-static" cargo build --target=x86_64-unknown-linux-musl --release
   Compiling helloworld v0.1.0 (/home/luke/Development/helloworld)
    Finished release [optimized] target(s) in 0.20s
$ file target/x86_64-unknown-linux-musl/release/helloworld
target/x86_64-unknown-linux-musl/release/helloworld: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, with debug_info, not stripped
$ ldd target/x86_64-unknown-linux-musl/release/helloworld
	statically linked
$ ./target/x86_64-unknown-linux-musl/release/helloworld
Hello World!

Meta

Details of my system:

$ uname -a
Linux x1 5.10.36-2-MANJARO #1 SMP PREEMPT Tue May 11 19:38:44 UTC 2021 x86_64 GNU/Linux
$ cargo --version --verbose
cargo 1.52.0 (69767412a 2021-04-21)
release: 1.52.0
commit-hash: 69767412acbf7f64773427b1fb53e45296712c3c
commit-date: 2021-04-21
$ rustc --version --verbose
rustc 1.52.1 (9bc8c42bb 2021-05-09)
binary: rustc
commit-hash: 9bc8c42bb2f19e745a63f3445f1ac248fb015e53
commit-date: 2021-05-09
host: x86_64-unknown-linux-gnu
release: 1.52.1
LLVM version: 12.0.0
$ musl-gcc --version
gcc (GCC) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat ~/.cargo/config 
# Configure cargo to use the "x86_64-linux-musl-gcc" binary for musl builds
#
# Replace the linker value if your musl compiler is named differently.
[target.x86_64-unknown-linux-musl]
linker = "musl-gcc"
$ cat Cargo.toml 
[package]
name = "helloworld"
version = "0.1.0"
authors = ["Luke Bond <redacted>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

[[bin]]
name = "helloworld"
path = "main.rs"

I expected to see this happen: No segfault and app prints "Hello World!".

Instead, this happened: segfault in debug mode.

Let me know if there is any other information I can share, or other tests I can run!

[nagisa]

Sounds like a potential duplicate of #84576

[lukebond]

if i add -Crelocation-model=static to RUSTFLAGS it no longer segfaults. this unblocks me and i'd be happy to close the issue but leaving it open in case it's a bug and the team want to track it.

[ghost]

I tried to do the same thing but neither -Copt-level nor -Crelocation-model=static fixed the issue for me (edit: found the reason, ld is lld on my machine, but -Clink-self-contained=n also fixed the issue for bfd and gold), -Clink-self-contained=n did instead. 🤔

Here is the backtrace:

* thread #1, name = 'segfault', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
  * frame #0: 0x00005555555692f3 segfault`_start_c + 317
    frame #1: 0x00005555555691b6 segfault`_start + 22

[bjorn3]

You shouldn't need TARGET_CC=musl-gcc. Rustc itself already knows how to link against musl libc. And in fact if you use musl-gcc it may be possible that both musl-gcc and rustc try to link against distinct copies of musl (the copy of musl-gcc and the copy bundled with rustc), which can lead to crashes or other issues.