Conversation
On RISC-V 32-bit (riscv32), the SYS_futex system call is often handled indirectly due to the use of a 64-bit time_t type. Specifically, while SYS_futex is not directly defined, a related syscall like SYS_futex_time64 can be used, Upstream-Status: Submitted [Amanieu#485] Signed-off-by: Khem Raj <raj.khem@gmail.com>
| .as_ref() | ||
| .map(|ts_ref| ts_ref as *const _) | ||
| .unwrap_or(ptr::null()); | ||
| #[cfg(not(all(target_arch = "riscv32", target_env = "musl")))] |
There was a problem hiding this comment.
Why is this specific to musl? Shouldn't this affect all riscv32 targets?
There was a problem hiding this comment.
Why is this specific to musl? Shouldn't this affect all riscv32 targets?
glibc seems to alias SYS_futex to 64bit syscall, unlike musl
There was a problem hiding this comment.
This is still incorrect on musl because libc currently defines timespec as using 32-bit time while the syscall expects a 64-bit timespec:
src/unix/linux_like/linux/musl/mod.rs:pub type time_t = c_long;
Proper support for riscv32 would require some work in libc to support these types.
There was a problem hiding this comment.
Thats a rust libc bug you have uncovered :) because unlike glibc time_t is always 64bit on musl for all architectures ( both 32bit and 64bit) so that value should perhaps use dedicated 64bit type instead of c_ulong
There was a problem hiding this comment.
This is what musl has
arch/aarch64/bits/alltypes.h.in:#define _Int64 long
arch/arm/bits/alltypes.h.in:#define _Int64 long long
arch/i386/bits/alltypes.h.in:#define _Int64 long long
arch/loongarch64/bits/alltypes.h.in:#define _Int64 long
arch/m68k/bits/alltypes.h.in:#define _Int64 long long
arch/microblaze/bits/alltypes.h.in:#define _Int64 long long
arch/mips/bits/alltypes.h.in:#define _Int64 long long
arch/mips64/bits/alltypes.h.in:#define _Int64 long
arch/mipsn32/bits/alltypes.h.in:#define _Int64 long long
arch/or1k/bits/alltypes.h.in:#define _Int64 long long
arch/powerpc/bits/alltypes.h.in:#define _Int64 long long
arch/powerpc64/bits/alltypes.h.in:#define _Int64 long
arch/riscv32/bits/alltypes.h.in:#define _Int64 long long
arch/riscv64/bits/alltypes.h.in:#define _Int64 long
arch/s390x/bits/alltypes.h.in:#define _Int64 long
arch/sh/bits/alltypes.h.in:#define _Int64 long long
arch/x32/bits/alltypes.h.in:#define _Int64 long long
arch/x86_64/bits/alltypes.h.in:#define _Int64 long
include/alltypes.h.in:TYPEDEF _Int64 time_t;
There was a problem hiding this comment.
Yes, the libc bug needs to be addressed before this PR can be merged.
There was a problem hiding this comment.
I don't see dependency with libc bug for this PR
There was a problem hiding this comment.
I have created a PR for rust libc as well
rust-lang/libc#4581
There was a problem hiding this comment.
This bug has been addressed in the libc commit Could this PR now be merged ?
On RISC-V 32-bit (riscv32), the SYS_futex system call is often handled indirectly due to the use of a 64-bit time_t type. Specifically, while SYS_futex is not directly defined, a related syscall like SYS_futex_time64 can be used on target e.g. riscv32 Signed-off-by: Khem Raj <raj.khem@gmail.com>
4 participants
On RISC-V 32-bit (riscv32), the SYS_futex system call is often handled indirectly due to the use of a 64-bit time_t type. Specifically, while SYS_futex is not directly defined, a related syscall like SYS_futex_time64 can be used,