linux(uclibc): add cfg option for file offset bindings on 32-bit targets#5165
linux(uclibc): add cfg option for file offset bindings on 32-bit targets#5165dybucc wants to merge 1 commit into
cfg option for file offset bindings on 32-bit targets#5165Conversation
dybucc
force-pushed
the
uclibc-file-offset-transition
branch
from
8755269 to
c883cf6
Compare
|
It would be ideal if this could be gated behind a
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. |
dybucc
changed the title
dybucc
force-pushed
the
uclibc-file-offset-transition
branch
2 times, most recently
from
19237c8 to
0ca05d1
Compare
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
force-pushed
the
uclibc-file-offset-transition
branch
from
bfeb785 to
c120d9a
Compare
|
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 A bunch of the suffixed type definitions were removed from the |
|
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 |
|
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
changed the title
cfg option for file offset bindings on 32-bit targets
rustbot
added
the
stable-nominated
|
Do these changes necessitate a minimum version of uclibc in order to pass the libc tests? I see that the checkbox indicating the libc-test has not been marked complete. Please make sure you do so, because there's often some subtle bugs which the tests catch! As for the 32- vs 64-bit file lengths, it's my experience that the length of this field varies between uclibc configurations. Is that understanding not up to date? |
|
☔ The latest upstream changes (possibly #5144) made this pull request unmergeable. Please resolve the merge conflicts. |
4 participants
Description
This PR adds a new
cfgfor file offset types in uClibc to ensure target triples 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 LFS64 types continue being exposed by default in all platforms, but when the
cfgoption is issued, they will have equivalent definitions to the unsuffixed types.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
Upstream uclibc-ng sources showing
ino_tdefined in terms of its 64-bit variant, and the definition for the 64-bit variant. There's a "chain" of types that leads to the final type with whichino64_tis defined. This chain is made most obvious by the final type alias, which appends a_TYPEand prepends two underscores to the type identifier in question. Notice how the__uquad_ttype is always defined as a 64-bit type, even on systems where that 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-bit variant when LFS64 support and__USE_FILE_OFFSET64are enabled. Much like the 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-bit variant when LFS64 support and__USE_FILE_OFFSET64are enabled. This follows the same reasoning as the above.Upstream uclibc-ng sources showing
rlim_tdefined in terms of its 64-bit variant. This follows the same reasoning as the above.Upstream uclibc-ng sources showing
fsblckcnt_tandfsfilcnt_tdefined in terms 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 same record layout. The second source shows how this definition can actually be unified across all child modules to theuclibcmodule because the fields that are conditionally compiled under MIPS will never be any different if__USE_FILE_OFFSET64is defined.Upstream uclibc-ng sources showing how
statvfsandstatvfs64are independent, but like the above, have equivalent definitions when__USE_FILE_OFFSET64is defined. This also shows how there does not seem to be a need for the fields to be reordered depending on the system's endianness.Upstream uclibc-ng sources showing how
statfsandstatfs64are independent, but like the above, have equivalent definitions when__USE_FILE_OFFSET64is defined. A bunch of field types were changed to both accurately 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 the definitions 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-specificcfg.Checklist
libc-test/semverhave been updated*LASTor*MAXare included (see #3131)cd libc-test && cargo test --target mytarget); especially relevant for platforms that may not be checked in CI@rustbot label +stable-nominated