linux(uclibc): add cfg for LFS bindings#5315
Open
dybucc wants to merge 3 commits into
Open
Conversation
rustbot
added
O-arm
O-linux
O-linux-like
O-mips
O-unix
S-waiting-on-review
stable-nominated
4 tasks
Adds a `cfg` to enable LFS64 bindings under 32-bit targets. This does not apply to 64-bit targets. Their suffixed types are equivalent to their unsuffixed types. They unconditionally get both suffixed and unsuffixed types. This `cfg` replicates a build option upstream.
Fixes the definitions of: - `stat`. - `statfs`. - `statvfs`. The analogous 64-bit types wer also tweaked. They are equivalent on some target architectures. They only needed to be aliased.
Replaces existing definitions. They were not correct under MIPS. This target needed some special casing.
dybucc
force-pushed
the
uclibc-lfs-support
branch
from
July 22, 2026 14:12
6d404a0 to
729cebc
Compare
Collaborator
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR adds a new
cfgfor file offset types in uClibc to ensure targettriples with a 32-bit machine word size can also have 64-bit unsuffixed file
offset types. None of these changes affect 64-bit platforms.
The LFS types continue being exposed by default in all platforms, but when the
cfgoption is issued, they will have equivalent definitions to the unsuffixedtypes.
Would like to ask @operutka, @lancethepants, @skrap and @japaric whether you
think it's worth it to add this
cfg, you folks being or having beenmaintainers for targets using uClibc. It was originally part of #5165, but got
split because our need to customize rust-lang/libc to fit upstream build options
wasn't entirely clear.
Sources
Upstream uclibc-ng sources showing
ino_tdefined in terms of its 64-bitvariant, and the definition for the 64-bit variant. There's a "chain" of types
that leads to the final type with which
ino64_tis defined. This chain ismade most obvious by the final type alias, which appends a
_TYPEandprepends two underscores to the type identifier in question. Notice how the
__uquad_ttype is always defined as a 64-bit type, even on systems wherethat requires using a record type with a two-element array (32-bit per
element).
Upstream uclibc-ng sources showing
off_tdefined in terms of its 64-bitvariant when LFS64 support and
__USE_FILE_OFFSET64are enabled. Much likethe above, there's a "chain" of types leading to the type whose bitwidth is
made clear. The chain is shortened to the last few types.
Upstream uclibc-ng sources showing
rlim_tdefined in terms of its 64-bitvariant when LFS64 support and
__USE_FILE_OFFSET64are enabled. This followsthe same reasoning as the above.
Upstream uclibc-ng sources showing
blkcnt_tdefined in terms of its 64-bitvariant. This follows the same reasoning as the above.
Upstream uclibc-ng sources showing
fsblckcnt_tandfsfilcnt_tdefined interms of their 64-bit variants. This first of the below sources also includes
references to the above types.
Upstream uclibc-ng sources showing how
flockandflock64are independent,but when defined with
__USE_FILE_OFFSET64, will end up having the samerecord layout. The second source shows how this definition can actually be
unified across all child modules to the
uclibcmodule because the fieldsthat are conditionally compiled under MIPS will never be any different if
__USE_FILE_OFFSET64is defined.Upstream uclibc-ng sources showing how
statvfsandstatvfs64areindependent, but like the above, have equivalent definitions when
__USE_FILE_OFFSET64is defined. This also shows how there does not seem tobe a need for the fields to be reordered depending on the system's endianness.
Upstream uclibc-ng sources showing how
statfsandstatfs64areindependent, but like the above, have equivalent definitions when
__USE_FILE_OFFSET64is defined. A bunch of field types were changed to bothaccurately reflect the upstream types used, and to add missing fields. The
former has not been documented in full in the below sources because the types
involved are already part of the sources cited in other list items. Some
required special-casing in MIPS platforms has been necessary, as there were
fields that had altogether different types. These were only ever so slightly
tweaked for the same reasons as above.
statfsin MIPS got unified as thedefinitions for both the o32 and N64/N32 ABIs are equivalent under
__USE_FILE_OFFSET64.Upstream uclibc-ng sources showing the same as the above but for
statandstat64. There was also some special casing required in MIPS platforms,though the definitions for both x86_64 and arm converged. These have been kept
in their corresponding modules because there's need for MIPS to have their own
and it was decided against a top-level, field-specific
cfg.Checklist
libc-test/semverhave been updated*LASTor*MAXhave the standarddoc comment
cargo test -p libc-test --target mytarget); especiallyrelevant for platforms that may not be checked in CI
@rustbot label +stable-nominated