Skip to content

musl: mips64: Fix type of nlink_t #4509

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

Merged
merged 1 commit into from
Jul 2, 2025

Conversation

Gelbpunkt
Copy link
Contributor

Description

musl defines nlink_t to be an unsigned 32-bit integer on mips64, therefore changing the size of stat64 from 216 bytes to 208.

The current definition in the libc crate does not match this and therefore defines stat64 wrong on mips64 musl, which results in bogus readings of fields following st_nlink.

See https://git.musl-libc.org/cgit/musl/tree/arch/mips64/bits/alltypes.h.in#n22 for the musl definition of nlink_t.

See also https://godbolt.org/z/6Ed3fvv76 for a godbolt link that confirms the sizes.

Without this change, the Rust compiler is completely broken on mips64-unknown-linux-muslabi64: it fails to mmap builtin libraries because it thinks their size is 0! It isn't, the field offset is just wrongly defined in libc.

Sources

https://git.musl-libc.org/cgit/musl/tree/arch/mips64/bits/alltypes.h.in#n22

https://godbolt.org/z/6Ed3fvv76

Checklist

  • Relevant tests in libc-test/semver have been updated
  • No placeholder or unstable values like *LAST or *MAX are
    included (see #3131)
  • Tested locally (cd libc-test && cargo test --target mytarget);
    especially relevant for platforms that may not be checked in CI

@Gelbpunkt Gelbpunkt force-pushed the musl-misp64-nlink branch from a859052 to 54c7267 Compare July 2, 2025 07:46
@Gelbpunkt Gelbpunkt requested a review from tgross35 July 2, 2025 07:52
Copy link
Contributor

@tgross35 tgross35 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@tgross35 tgross35 enabled auto-merge July 2, 2025 07:57
musl defines nlink_t to be an unsigned 32-bit integer on mips64,
therefore changing the size of stat64 from 216 bytes to 208.

The current definition in the libc crate does not match this and
therefore defines stat64 wrong on mips64 musl, which results in bogus
readings of fields following st_nlink.

See
https://git.musl-libc.org/cgit/musl/tree/arch/mips64/bits/alltypes.h.in#n22
for the musl definition of nlink_t.

Signed-off-by: Jens Reidel <[email protected]>
@tgross35 tgross35 force-pushed the musl-misp64-nlink branch from 54c7267 to 02eff0f Compare July 2, 2025 08:03
@tgross35 tgross35 added this pull request to the merge queue Jul 2, 2025
Merged via the queue into rust-lang:main with commit 14efd35 Jul 2, 2025
50 of 51 checks passed
@Gelbpunkt
Copy link
Contributor Author

Since this fixes rustc:

@rustbot label +stable-nominated

@rustbot rustbot added the stable-nominated This PR should be considered for cherry-pick to libc's stable release branch label Jul 3, 2025
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 8, 2025
…labi64-target-maintainer, r=jieyouxu

Add target maintainer information for mips64-unknown-linux-muslabi64

The `mips64-unknown-linux-muslabi64` target is currently rather broken, but I'm working on getting it fixed so that it can at least be used again.

While I can't commit to maintaining the LLVM side of this target, I don't mind looking into any other MIPS or musl-related issues that arise with this target.

See e.g. rust-lang#143409 for some rustc fixes I have in the pipeline and rust-lang/libc#4509, rust-lang/libc#4527, rust-lang/libc#4528, rust-lang/libc#4529, rust-lang/libc#4530 for fixing the libc definitions for this target.

I'm adding myself as a maintainer mostly due to [this interaction](rust-lang/libc#4530 (comment)).

LLVM support has been a concern for these targets in the past, but it shouldn't hurt to have a nominal maintainer for these even if they remain tier 3. From my experience, LLVM for MIPS is working well nowadays unless you decide to use LLD, which is horribly broken on MIPS.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 8, 2025
…labi64-target-maintainer, r=jieyouxu

Add target maintainer information for mips64-unknown-linux-muslabi64

The `mips64-unknown-linux-muslabi64` target is currently rather broken, but I'm working on getting it fixed so that it can at least be used again.

While I can't commit to maintaining the LLVM side of this target, I don't mind looking into any other MIPS or musl-related issues that arise with this target.

See e.g. rust-lang#143409 for some rustc fixes I have in the pipeline and rust-lang/libc#4509, rust-lang/libc#4527, rust-lang/libc#4528, rust-lang/libc#4529, rust-lang/libc#4530 for fixing the libc definitions for this target.

I'm adding myself as a maintainer mostly due to [this interaction](rust-lang/libc#4530 (comment)).

LLVM support has been a concern for these targets in the past, but it shouldn't hurt to have a nominal maintainer for these even if they remain tier 3. From my experience, LLVM for MIPS is working well nowadays unless you decide to use LLD, which is horribly broken on MIPS.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 8, 2025
…labi64-target-maintainer, r=jieyouxu

Add target maintainer information for mips64-unknown-linux-muslabi64

The `mips64-unknown-linux-muslabi64` target is currently rather broken, but I'm working on getting it fixed so that it can at least be used again.

While I can't commit to maintaining the LLVM side of this target, I don't mind looking into any other MIPS or musl-related issues that arise with this target.

See e.g. rust-lang#143409 for some rustc fixes I have in the pipeline and rust-lang/libc#4509, rust-lang/libc#4527, rust-lang/libc#4528, rust-lang/libc#4529, rust-lang/libc#4530 for fixing the libc definitions for this target.

I'm adding myself as a maintainer mostly due to [this interaction](rust-lang/libc#4530 (comment)).

LLVM support has been a concern for these targets in the past, but it shouldn't hurt to have a nominal maintainer for these even if they remain tier 3. From my experience, LLVM for MIPS is working well nowadays unless you decide to use LLD, which is horribly broken on MIPS.
rust-timer added a commit to rust-lang/rust that referenced this pull request Jul 8, 2025
Rollup merge of #143622 - Gelbpunkt:mips64-unknown-linux-muslabi64-target-maintainer, r=jieyouxu

Add target maintainer information for mips64-unknown-linux-muslabi64

The `mips64-unknown-linux-muslabi64` target is currently rather broken, but I'm working on getting it fixed so that it can at least be used again.

While I can't commit to maintaining the LLVM side of this target, I don't mind looking into any other MIPS or musl-related issues that arise with this target.

See e.g. #143409 for some rustc fixes I have in the pipeline and rust-lang/libc#4509, rust-lang/libc#4527, rust-lang/libc#4528, rust-lang/libc#4529, rust-lang/libc#4530 for fixing the libc definitions for this target.

I'm adding myself as a maintainer mostly due to [this interaction](rust-lang/libc#4530 (comment)).

LLVM support has been a concern for these targets in the past, but it shouldn't hurt to have a nominal maintainer for these even if they remain tier 3. From my experience, LLVM for MIPS is working well nowadays unless you decide to use LLD, which is horribly broken on MIPS.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-linux O-mips O-musl O-unix stable-nominated This PR should be considered for cherry-pick to libc's stable release branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants