Skip to content

linux(uclibc): add cfg option for file offset bindings on 32-bit targets#5165

Draft
dybucc wants to merge 1 commit into
rust-lang:mainfrom
dybucc:uclibc-file-offset-transition
Draft

linux(uclibc): add cfg option for file offset bindings on 32-bit targets#5165
dybucc wants to merge 1 commit into
rust-lang:mainfrom
dybucc:uclibc-file-offset-transition

Conversation

@dybucc

@dybucc dybucc commented Jun 13, 2026

Copy link
Copy Markdown
Contributor

Description

This PR adds a new cfg for file offset types in uClibc to ensure target triples with a 32-bit machine word size can also have 64-bit unsuffixed types. None of these changes affect 64-bit platforms.

The LFS64 types continue being exposed by default in all platforms, but when the cfg option is issued, they will have equivalent definitions to the unsuffixed types.

The only exceptions to this were records that are specifically not aliased in terms of their 64-bit "variants," but are rather both exposed in upstream uclibc-ng. Examples of this include stat and statfs.

There were also some records that were altogether removed because they collided with structures from top-level modules such as unix/linux_like/linux_l4re_shared.

Sources

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

@rustbot label +stable-nominated

@dybucc dybucc marked this pull request as draft June 13, 2026 09:12
@dybucc dybucc force-pushed the uclibc-file-offset-transition branch from 8755269 to c883cf6 Compare June 15, 2026 13:58
@tgross35

Copy link
Copy Markdown
Contributor

It would be ideal if this could be gated behind a cfg, similar to what we have on musl and glibc, to give users a chance to test things out prior to 1.0. Same for any other platforms that haven't had this done yet. I'm less concerned about it for tier 3 targets but would have some reservations about merging this or other PRs that only target main until we're closer to 1.0, given how conflict-prone it tends to make any backports.

There's one record I'm particularily doubtful of. In libc we choose to expose ever so slightly different definition for the statvfs structure depending on the target's endianness. This only affects whether a field appears before or after some padding, the latter of which depends on the target's word size. Other modules under the uclibc module do not seem to use this endian-dependent field ordering, so that has been removed as there's neither any indication in the upstream definition of there being need for that. Still, this is very much a change prone to reversion, if I'm, indeed, missing something. Input here is very much welcome.

That very well could have been a copy+paste error, I very much doubt anybody is using these structs on uclibc today to the point that these kind of bugs would show up.

@tgross35

Copy link
Copy Markdown
Contributor

The author of #5046 indicated that uclibc has a preference for keeping the small sizes, so I think this will need to remain configurable even post-1.0.

Cc @skrap for your thoughts here.

@dybucc dybucc changed the title refactor: change file off bindings in linux uclibc linux(uclibc): change file offset bindings Jun 19, 2026
@dybucc dybucc force-pushed the uclibc-file-offset-transition branch 2 times, most recently from 19237c8 to 0ca05d1 Compare June 20, 2026 08:40
@rustbot rustbot added the A-CI Area: CI-related items label Jun 20, 2026
The currently exposed bindings to file offset types and routines are
often found to be either lacking or incorrect in the current worktree.
This has been fixed by means of changing multiple type definitions
across child modules of the `linux/uclibc` module, such that a more
cohesive interface is exposed.

Types with LFS64 variants in 32-bit platforms will now have equivalent
definitions to their "unsuffixed" variants if the
`uclibc_file_offset_bits` `cfg` is set. In 64-bit machine word targets,
both the unsuffixed and suffixed types are unconditionally exposed with
the same bit width.
@dybucc dybucc force-pushed the uclibc-file-offset-transition branch from bfeb785 to c120d9a Compare June 20, 2026 09:05
@dybucc

dybucc commented Jun 20, 2026

Copy link
Copy Markdown
Contributor Author

Just read through that PR and the comments. I'm not quite sure I understand why that is the case. Hopefully the maintainer can clear things up (not pinging again.)

I've already updated the PR with support for the cfg. The option ensures the unsuffixed types are exposed for targets with a 32-bit machine word size, as otherwise suffixed and unsuffixed types are equivalent.

A bunch of the suffixed type definitions were removed from the uclibc module in favor of the top-level unix, unix/linux_like and unix/linux_like/linux modules. Those already provide the base types for most file offset types. The rest have been left in the linux/uclibc module.

@dybucc

dybucc commented Jun 20, 2026

Copy link
Copy Markdown
Contributor Author

The CI label is wrong. At one point, I changed files concerning CI but I then realized all targets using uClibc are tier 3, and the only included target in verify_build.py uses L4Re and not Linux.

@rustbot

rustbot commented Jun 20, 2026

Copy link
Copy Markdown
Collaborator

Error: Label A-CI can only be set by Rust team members

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #triagebot on Zulip.

@dybucc dybucc changed the title linux(uclibc): change file offset bindings linux(uclibc): add cfg option for file offset bindings on 32-bit targets Jun 20, 2026
@rustbot rustbot added the stable-nominated This PR should be considered for cherry-pick to libc's stable release branch label Jun 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-CI Area: CI-related items 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