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

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.

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)

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

rustbot · 2025-12-05T12:02:05Z

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.

xbjfk · 2025-12-05T12:02:15Z

Rebased on top of of main (mostly #4479) - let me know if there are any other changes I should make, or if I should re-order commits to make releases easier :)
Looks like I may have broken android style checking - will need to investigate more.
I'm happy to make a new PR changing struct stat fields to be timespec for the 1.0 branch after this one

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-08T05:13:37Z

Actually looks like pub use musl::sched:: needs to be in "Per env headers we export" and closer match musl source code..

tgross35

I don't see anything major here, so let's get this in!

Thank you for taking all the time to prepare and update this PR ❤️

I do have one remaining comment, would you mind sending a followup PR addressing it?

tgross35 · 2025-12-04T18:59:06Z

src/new/emscripten/sched.rs

+cfg_if! {
+    if #[cfg(musl_v1_2_3)] {
+        s! {
+            struct __c_anon_sched_param__reserved2 {
+                __reserved1: crate::time_t,
+                __reserved2: c_long,
+            }
+
+            pub struct sched_param {
+                pub sched_priority: c_int,
+
+                __reserved1: Padding<c_int>,
+                #[cfg(musl32_time64)]
+                __reserved2: Padding<[c_long; 4]>,
+                #[cfg(not(musl32_time64))]
+                __reserved2: Padding<[__c_anon_sched_param__reserved2; 2]>,
+                __reserved3: Padding<c_int>,
+            }
+        }
+    } else {
+        s! {
+            pub struct sched_param {
+                pub sched_priority: c_int,
+
+                #[deprecated(since = "0.2.173", note = "This field has been removed upstream")]
+                pub sched_ss_low_priority: c_int,
+                #[deprecated(since = "0.2.173", note = "This field has been removed upstream")]
+                pub sched_ss_repl_period: crate::timespec,
+                #[deprecated(since = "0.2.173", note = "This field has been removed upstream")]
+                pub sched_ss_init_budget: crate::timespec,
+                #[deprecated(since = "0.2.173", note = "This field has been removed upstream")]
+                pub sched_ss_max_repl: c_int,
+            }
+        }
+    }
+}


This cfg isn't ever set on emscripten right? It just needs the old defs with deprecated

martinetd · 2025-12-17T08:12:41Z

Thank you both!

For people following from the sidelines like me, could someone confirm what this means in practice -- is the plan to backport part of this to 0.2, or will users have to wait until the 1.0 release? (The tracking issue still has quite a few points but I'm not clear how up to date it is...)

Sorry for taking your time on paperwork, I'd just like to get an idea on when users will be able to use this (I'd probably need to prepare a separate rust build for our older arm32 systems if this still more than a couple of years away)

tgross35 · 2025-12-17T08:29:53Z

The plan is for 0.2 indeed, I’ll backport it soon then it will be usable under the unstable env. Eventually I’d like to come up with a more stable way to control this (probably a cfg you can set via RUSTFLAGS), which will also make it to 0.2 and replace the env. Same story for glibc.

When we actually have the 1.0 release we’ll drop the cfg and default to 64-bit time_t on all platforms.

Until then, testing is very much appreciated :)

martinetd · 2025-12-17T09:46:13Z

Great, thanks for confirming!

I did a build with this branch back in June and it worked fine (at least I didn't notice any weird behavior, and my server didn't break when manually setting the date past 2038), but I'll definitely make time to retest at various parts of the process (soonish on master as a couple of things changed since, and when it gets backported etc), feel free to ping me if you want testing on later PRs and you remember (no harm either way).

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 81dcc04 to 1334069 Compare December 4, 2025 13:40

xbjfk added 8 commits December 5, 2025 11:13

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

5383a4d

musl: Merge stat64 and stat with stat

a1c27ef

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

08bd83c

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

cb722b4

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

musl: time64: set link names for symbols

dea3254

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

musl: time64: update struct sched_param

dc62309

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

musl: convert inline timespecs to timespec

067f2c2

musl: time64: change time_t type and structs

0334b72

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

xbjfk force-pushed the musl-time64 branch from 1334069 to 9fa51cc Compare December 5, 2025 12:02

xbjfk added 3 commits December 5, 2025 12:44

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

8673f86

This fixes test failures on musl.

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

7447403

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

xbjfk force-pushed the musl-time64 branch from 9fa51cc to d343982 Compare December 5, 2025 12:47

xbjfk added 3 commits December 6, 2025 10:56

libc-test: delete handle_s_macro_no_attrs

6b4f34e

Unfortunately does not seem to handle cfg_if well

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

b5153ba

This reverts commit 34e7583.

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

89b5220

This reverts commit 72fe537.

xbjfk force-pushed the musl-time64 branch from d343982 to 89b5220 Compare December 6, 2025 10:56

tgross35 approved these changes Dec 17, 2025

View reviewed changes

tgross35 added this pull request to the merge queue Dec 17, 2025

Merged via the queue into rust-lang:main with commit 7726e8f Dec 17, 2025
50 of 51 checks passed

tgross35 mentioned this pull request Dec 18, 2025

linux: Use the input_event_X macros to access input_event members #4654

Open

3 tasks

musl: 64-bit time support #4463

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!

xbjfk commented Dec 4, 2025

Uh oh!

rustbot commented Dec 5, 2025

Uh oh!

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

Uh oh!

Uh oh!

xbjfk commented Dec 8, 2025

Uh oh!

tgross35 left a comment

Choose a reason for hiding this comment

Uh oh!

tgross35 Dec 4, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

martinetd commented Dec 17, 2025

Uh oh!

tgross35 commented Dec 17, 2025

Uh oh!

martinetd commented Dec 17, 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

xbjfk commented Dec 5, 2025 •

edited

Loading