musl: 64-bit time support #4463

xbjfk · 2025-05-26T12:19:15Z

Description

This change includes time64 support for applicable architectures (x86, arm, mips and powerpc). This is based on the previous PRs to this repo as well as the musl changelog from 1.1.24 -> 1.2. It can be enabled with the environment variable
RUST_LIBC_UNSTABLE_MUSL_TIME64 only when musl_v1_2_3 is enabled and the architecture is supported.

A lot of structures, especially ones with mixed endian became excessively complicated, so I used cfg_if to separate them. It looks like you can only nest s! {} in cfg_if! {}, but not vice versa.

As a note, I'm considering removing musl_not_time64, and just keeping the old logic of allowing deprecated for function definitions involving time_t as it introduces necessary complexity.

When libc 1.0 is released, I believe the best path would be to remove the musl_v1_2_3 feature, making it unconditionally enabled, keeping musl_time64 which will expand to (musl && time64_arch).

Tested through QEMU for all architectures.

Sources

Sources are located on each commit, in the form of upstream commits

Checklist

Relevant tests in libc-test/semver have been updated
No placeholder or unstable values like *LAST or *MAX are
included (see rust-lang/libc#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

xbjfk · 2025-05-26T12:22:55Z

Hmm, seems like the style checker isn't happy with mixing s! {} and cfg_if! {}, and putting cfg_if! {} inside an s! {} block does not seem to work either. I'm not sure what the best course of action is regarding this.

xbjfk · 2025-05-30T12:08:42Z

Since #4433 seems close to merging, I can rebase on top of it once merged.

xbjfk · 2025-06-03T09:09:05Z

Rebased on top of the GNU changes :)

tgross35 · 2025-06-03T17:51:54Z

Thanks! Sorry it's taken me a while, I'll try to look at this very soon

tgross35

Thanks for working on this! Left a few comments here.

For the style check, are the changes it is suggesting possible? If not, that will probably have to be updated unfortunately (hopefully we will be able to reorganize things at some point so it's less annoying...)

build.rs

ci/run-docker.sh

build.rs

src/unix/linux_like/linux/mod.rs

xbjfk · 2025-06-15T10:50:57Z

Thanks for the review! I'll get around to implementing the changes hopefully in the next few days. I'll try figure out how to pass the style lints - but it might need a new file.

After this merges and when 1.0 is closer to release feel free to ping me on GitHub and I can help fully complete the transition for these changes in the 1.0 branch on the musl side :).

src/unix/mod.rs

tgross35 · 2025-11-02T09:16:55Z

Okay, I've addressed most comments - unfortunately, it seems like there is an issue with compiling for hexagon - but it looks like it still appears on main.

Fyi we're skipping hexagon now, should be picked up if you rebase

tgross35 · 2025-11-30T09:53:11Z

@xbjfk gentle ping here, would you be able to take a look at this? If you're able to rebase I can probably apply at least a few of the patches from this series, to reduce the remaining surface area.

xbjfk · 2025-12-02T13:19:50Z

Thanks for the nudge! Have rebased and applied most comments. Still need to confirm why input_event and make sure to double check and add missing Paddings (only did it near merge conflicts). Also need to find a nice way to handle sched_param on emscripten without failing - might just need to duplicate the struct

src/unix/linux_like/linux/musl/b64/riscv64/mod.rs

src/unix/mod.rs

src/new/musl/sched.rs

src/unix/linux_like/linux/musl/b32/mips/mod.rs

tgross35 · 2025-12-03T06:14:27Z

src/new/mod.rs

    } else if #[cfg(target_os = "emscripten")] {
        mod emscripten;
        pub(crate) use emscripten::*;
+        pub use musl::sched::sched_util;


For the test failure: drop this bit...

tgross35 · 2025-12-03T06:16:45Z

src/unix/linux_like/mod.rs

+    #[cfg(not(any( target_env = "musl", target_os = "emscripten", target_env = "ohos")))]
    pub struct sched_param {
        pub sched_priority: c_int,
-        #[cfg(any(target_env = "musl", target_os = "emscripten", target_env = "ohos"))]
-        pub sched_ss_low_priority: c_int,
-        #[cfg(any(target_env = "musl", target_os = "emscripten", target_env = "ohos"))]
-        pub sched_ss_repl_period: crate::timespec,
-        #[cfg(any(target_env = "musl", target_os = "emscripten", target_env = "ohos"))]
-        pub sched_ss_init_budget: crate::timespec,
-        #[cfg(any(target_env = "musl", target_os = "emscripten", target_env = "ohos"))]
-        pub sched_ss_max_repl: c_int,
    }


... and restore these fields, but with only #[cfg(target_os = "emscripten")] (update the cfg(not) of course.

Or create a src/new/emscripten/sched.rs file and copy the deprecated version from musl there.

src/unix/linux_like/linux/musl/b32/arm/mod.rs

tgross35 · 2025-12-03T06:31:30Z

Still need to confirm why input_event and make sure to double check and add missing Paddings (only did it near merge conflicts). Also need to find a nice way to handle sched_param on emscripten without failing - might just need to duplicate the struct

Oh, sorry, that's most of what I just left comments about 😆 I think this is very close to ready though

tgross35 · 2025-12-03T09:19:41Z

Sorry for the conflicts here - more padding changes in #4862, and a build config update in 5c4255f.

The structures are the same - and this follows the upstream definition On musl at least, blkcnt64_t == blkcnt_t == i64 and ino_t == ino64_t == u64

This feature is enabled with independently from musl_v1_2_3 to support time64. Defining this feature makes this roughly equivalent to upstream commit bminor/musl@f12bd8e.

This is equivalent to upstream commit bminor/musl@9b2921b.

This corresponds to upstream commit bminor/musl@1febd21 (most symbols) and bminor/musl@22daaea (only dlsym)

rustbot · 2025-12-04T12:22:43Z

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.

A bunch of properties were removed upstream and set to reserved. This matches upstream commit bminor/musl@827aa8f and bminor/musl@2d69fcf

Change time_t type to i64 Change struct stat, msqid_ds and shmid_ds to reflect This commit follows upstream bminor/musl@3814333 and bminor/musl@d6dcfe4 It also implements a fix from bminor/musl@0fbd7d6

This is primarily based on a small part of bminor/musl@3814333. This also integrates bminor/musl@3c02bac, which update MSG_STAT, SEM_STAT, SEM_STAT_ANY. These are based on the value of IPC_STAT, however we can just use `cfg` as it is effectively the same.

This fixes test failures on musl.

Namely, this allows `target_endian` as well as adds a constant array where certain configs are explicitly allowed (e.g. musl32_time64).

Unfortunately does not seem to handle cfg_if well

This reverts commit 34e7583.

This reverts commit 72fe537.

xbjfk · 2025-12-04T13:42:57Z

Okay - I should have resolved everything. I added a commit to change stat's inlined timespec to simply timespec and changed the tests to account for that. Note the naming is different - st_xtim instead of st_xtime. It seems migration to timespec was done in POSIX 2008 - man 3 stat has more info

I also reverted the commit which disabled time related tests. I'll fix any test failures hopefully tomorrow.

rustbot added A-CI Area: CI-related items O-arm O-linux O-linux-like O-mips O-musl O-unix O-x86 S-waiting-on-review stable-nominated This PR should be considered for cherry-pick to libc's stable release branch labels May 26, 2025

xbjfk changed the title ~~musl: time64~~ musl: 64-bit time support May 26, 2025

xbjfk mentioned this pull request May 26, 2025

Start update to musl v1.2.3 #4443

Merged

5 tasks

xbjfk force-pushed the musl-time64 branch 6 times, most recently from 8b32bb3 to e91f182 Compare June 3, 2025 08:26

tgross35 requested changes Jun 9, 2025

View reviewed changes

build.rs Outdated Show resolved Hide resolved

ci/run-docker.sh Show resolved Hide resolved

build.rs Show resolved Hide resolved

src/unix/linux_like/linux/mod.rs Outdated Show resolved Hide resolved

This was referenced Jun 19, 2025

Rebase of "Upgrade musl supported version to 1.2.3" #3791

Closed

Upgrade musl supported version to 1.2.3 #3068

Closed

musl: Change time_t definition on 32-bit targets according to "time64" #1848

Open

martinetd reviewed Jun 20, 2025

View reviewed changes

src/unix/mod.rs Outdated Show resolved Hide resolved

xbjfk force-pushed the musl-time64 branch 2 times, most recently from 9b5ca40 to f669296 Compare June 23, 2025 11:51

xbjfk force-pushed the musl-time64 branch from 9387345 to 7910758 Compare December 2, 2025 13:06

This comment has been minimized.

Sign in to view

xbjfk force-pushed the musl-time64 branch 2 times, most recently from c20d0e7 to b2c6f8e Compare December 2, 2025 13:18

tgross35 reviewed Dec 3, 2025

View reviewed changes

xbjfk added 5 commits December 4, 2025 12:05

musl: riscv: fix public padding fields in stat/stat64

c958a4a

musl: Merge stat64 and stat with stat

0f1d040

The structures are the same - and this follows the upstream definition On musl at least, blkcnt64_t == blkcnt_t == i64 and ino_t == ino64_t == u64

musl: add musl_time64 feature

5bde4db

This feature is enabled with independently from musl_v1_2_3 to support time64. Defining this feature makes this roughly equivalent to upstream commit bminor/musl@f12bd8e.

musl: time64: adjust struct timespec definition

f0f109b

This is equivalent to upstream commit bminor/musl@9b2921b.

musl: time64: set link names for symbols

ca18daa

This corresponds to upstream commit bminor/musl@1febd21 (most symbols) and bminor/musl@22daaea (only dlsym)

xbjfk force-pushed the musl-time64 branch from b2c6f8e to 64ee918 Compare December 4, 2025 12:22

musl: time64: update struct sched_param

831e189

A bunch of properties were removed upstream and set to reserved. This matches upstream commit bminor/musl@827aa8f and bminor/musl@2d69fcf

xbjfk force-pushed the musl-time64 branch 2 times, most recently from d15a765 to 81dcc04 Compare December 4, 2025 13:20

xbjfk added 8 commits December 4, 2025 13:36

musl: convert inline timespecs to timespec

eee3753

musl: time64: change time_t type and structs

37b5a3e

Change time_t type to i64 Change struct stat, msqid_ds and shmid_ds to reflect This commit follows upstream bminor/musl@3814333 and bminor/musl@d6dcfe4 It also implements a fix from bminor/musl@0fbd7d6

semver: linux powerpc: split GNU-specific symbols into own file.

1905ed6

This fixes test failures on musl.

libc-test: add allowlist for positive s! marco configs

b8c24a7

Namely, this allows `target_endian` as well as adds a constant array where certain configs are explicitly allowed (e.g. musl32_time64).

libc-test: delete handle_s_macro_no_attrs

32a4764

Unfortunately does not seem to handle cfg_if well

Revert "test: Skip input_event.time on recent musl"

4ba0df2

This reverts commit 34e7583.

Revert "test: musl: Skip time64-dependent API on new musl"

1334069

This reverts commit 72fe537.

xbjfk force-pushed the musl-time64 branch from 81dcc04 to 1334069 Compare December 4, 2025 13:40

musl: 64-bit time support #4463

Are you sure you want to change the base?

musl: 64-bit time support #4463

Uh oh!

Conversation

xbjfk commented May 26, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Sources

Checklist

Uh oh!

xbjfk commented May 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xbjfk commented May 30, 2025

Uh oh!

xbjfk commented Jun 3, 2025

Uh oh!

tgross35 commented Jun 3, 2025

Uh oh!

tgross35 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

xbjfk commented Jun 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

tgross35 commented Nov 2, 2025

Uh oh!

tgross35 commented Nov 30, 2025

Uh oh!

This comment has been minimized.

xbjfk commented Dec 2, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tgross35 Dec 3, 2025

Choose a reason for hiding this comment

Uh oh!

tgross35 Dec 3, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tgross35 commented Dec 3, 2025

Uh oh!

tgross35 commented Dec 3, 2025

Uh oh!

rustbot commented Dec 4, 2025

Uh oh!

xbjfk commented Dec 4, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

xbjfk commented May 26, 2025 •

edited by rustbot

Loading

xbjfk commented May 26, 2025 •

edited

Loading

xbjfk commented Jun 15, 2025 •

edited

Loading