LTO turns weak linkage into a miscompile (identified via `gettid` segfault on x86_64-unknown-linux-musl)

[alyssais]

View all comments

This is a very strange one. Since 289fe36 (I bisected; cc @tgross35), my program that calls libc's gettid segfaults when built for x86_64-unknown-linux-musl. However, I can only reproduce this when the call to gettid is in a library crate, and only when it has a certain name, and only when not using -C target-feature=-crt-static, only when using LTO.

Code

dep.rs

unsafe extern "C" {
    safe fn gettid() -> i32;
}

pub fn print_tid() {
    println!("{}", gettid());
}

main.rs

fn main() {
    vmm::print_tid();
}

Reproduction commands

rustc --crate-name vmm --edition=2024 dep.rs --crate-type lib -C opt-level=3 -C linker-plugin-lto --target x86_64-unknown-linux-musl -C linker=/nix/store/nz3n5wy8zadq73kkql2xn485l7xdmv46-x86_64-unknown-linux-musl-gcc-wrapper-15.2.0/bin/x86_64-unknown-linux-musl-cc
rustc --edition=2024 main.rs --crate-type bin -C opt-level=3 -C lto --target x86_64-unknown-linux-musl -C linker=/nix/store/nz3n5wy8zadq73kkql2xn485l7xdmv46-x86_64-unknown-linux-musl-gcc-wrapper-15.2.0/bin/x86_64-unknown-linux-musl-cc --extern vmm=libvmm.rlib
./main

Happy to provide LLVM IR or anything else that helps!

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged

[tgross35]

Well that's bizarre, it should be a straightforward function on the libc side. Any chance you're able to run this through a debugger?

only when it has a certain name

What do you mean by this?

[tgross35]

Could you also document the rust version you tested with?

I wonder if there's a bug in optimization that's messing with TLS. The call chain of gettid itself is dead simple:

• https://github.com/kraj/musl/blob/48e626ab6e03a86fa851b49f689b0cbea4cd98dd/src/linux/gettid.c#L7
• https://github.com/kraj/musl/blob/48e626ab6e03a86fa851b49f689b0cbea4cd98dd/src/internal/pthread_impl.h#L117-L123
• https://github.com/kraj/musl/blob/48e626ab6e03a86fa851b49f689b0cbea4cd98dd/arch/x86_64/pthread_arch.h#L4

[emilazy]

I wonder if https://github.com/rust-lang/rust/blob/23903d01c237d7c7d4fb62b82ca846bc45de4e0c/library/std/src/sys/pal/unix/weak/syscall.rs might have something to do with this, as it could potentially result in an actual syscall vs. Musl’s syscall‐free implementation of the call, depending on Circumstances™? The commit introducing that implementation ominously states “while conceptually this is a syscall, the copy stored in the thread structure is always valid in all contexts where it's valid to call libc functions”, though of course there’s no reason why the reproducer shouldn’t be in a valid context to call into libc.

[emilazy]

In particular perhaps the dlsym(3) call is picking up the non‐weak gettid extern import and something something ordering of symbol resolution means that the vmm crate name manages to become load‐bearing somehow…?

[tgross35]

The repro doesn't use std's gettid wrapper, it's just an extern call. I think that was just the original problem that identified the issue.

Slightly simplified repro, the result doesn't need to be used:

$ cat dep.rs
unsafe extern "C" {
    safe fn gettid() -> i32;
}

pub fn tid() -> i32 {
    gettid()
}
$ cat main.rs
fn main() {
    vmm::tid();
}
$ rustc --crate-name vmm --crate-type lib -C opt-level=3 --target x86_64-unknown-linux-musl dep.rs -g
$ rustc main.rs -C opt-level=3 -C lto --extern vmm=libvmm.rlib --target x86_64-unknown-linux-musl -g
$ ./main
Segmentation fault

[emilazy]

I was thinking it might affect what the weak::syscall! in the panic code gets for gettid. But of course the program presumably shouldn’t be calling into that part of the panic code at all? But if it bisects to 289fe36, then that call to current_os_id in default_hook that indirects to the lazy DlsymWeak for libc’s gettid seems like the only thing that could be possibly causing this, and if that isn’t ever being initialized then… ?

Some bizarre bug in Musl’s dynamic loader…?

[tgross35]

Would need @alyssais to confirm but I'm assuming that the bisection is for the original issue, not for the repro. IOW whatever bug this is has probably existed for a while, the fact that it shows up when panicking is just what surfaced it. (It also reproduces with -Cpanic=abort)

Adding the relevant labels assuming it's somewhere in the optimization pipeline.