Skip to content

Avoid weak-linking gettid on musl - #160114

Open
windsornguyen wants to merge 1 commit into
rust-lang:mainfrom
windsornguyen:fix/musl-lto-weak-gettid
Open

Avoid weak-linking gettid on musl#160114
windsornguyen wants to merge 1 commit into
rust-lang:mainfrom
windsornguyen:fix/musl-lto-weak-gettid

Conversation

@windsornguyen

Copy link
Copy Markdown

Mitigates #154439.

Summary

current_os_id weak-links gettid so older glibc can fall back to a raw syscall. Rust-supported musl versions provide gettid, so musl does not need that probe.

During fat LTO, LLVM can merge the weak declaration with a strong declaration from another crate and keep the weak linkage. A static linker then does not extract gettid.o from libc.a, leaving the strong call without a definition.

This calls gettid directly on musl. It follows the musl-specific branch suggested by @tgross35 in #154439. @bjorn3 traced the underlying compiler problem to fat LTO using LLVM’s legacy ModuleLinker; changing that compiler-level behavior is intentionally out of scope here, so the issue should remain open.

Test

The new run-pass test builds a strong gettid declaration in an auxiliary rlib that sorts after std, links it statically under fat LTO, and verifies that the main thread ID equals the process ID. It exits with SIGSEGV against the unpatched x86_64 musl standard library and passes with this change. The value assertion also catches targets where the bad call returns an incorrect thread ID instead of trapping.

Validated with:

  • The targeted stage 1 compiletest on x86_64-unknown-linux-musl
  • x.py fmt --check
  • x.py test tidy

r? @tgross35

`current_os_id` uses an extern-weak `gettid` declaration so older glibc
can fall back to a raw syscall. Rust-supported musl versions provide
`gettid`, so musl does not need this probe.

During fat LTO, LLVM can merge the weak declaration with a strong
reference from another crate and keep the weak linkage. The static
linker then does not extract `gettid.o` from `libc.a`, leaving the
strong call without a definition.

Call `gettid` directly on musl and add a regression test for the
returned thread ID. This removes std's contribution to the collision;
the underlying LTO linkage bug remains.
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jul 29, 2026
@rustbot

rustbot commented Jul 29, 2026

Copy link
Copy Markdown
Collaborator

tgross35 is currently at their maximum review capacity.
They may take a while to respond.

@rustbot

rustbot commented Jul 29, 2026

Copy link
Copy Markdown
Collaborator

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @tgross35 (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@windsornguyen

Copy link
Copy Markdown
Author

@bjorn3, since you identified the ModuleLinker root cause in #154439, would you be willing to give the LTO scope here a second look?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants