libstdc++: Use custom timespec in system calls [PR 93421]

On 32-bit targets where userspace has switched to 64-bit time_t, we
cannot pass struct timespec to SYS_futex or SYS_clock_gettime, because
the userspace definition of struct timespec will not match what the
kernel expects.

We use the existence of the SYS_futex_time64 or SYS_clock_gettime_time64
macros to imply that userspace *might* have switched to the new timespec
definition.  This is a conservative assumption. It's possible that the
new syscall numbers are defined in the libc headers but that timespec
hasn't been updated yet (as is the case for glibc currently). But using
the alternative struct with two longs is still OK, it's just redundant
if userspace timespec still uses a 32-bit time_t.

We also check that SYS_futex_time64 != SYS_futex so that we don't try
to use a 32-bit tv_sec on modern targets that only support the 64-bit
system calls and define the old macro to the same value as the new one.

We could possibly check #ifdef __USE_TIME_BITS64 to see whether
userspace has actually been updated, but it's not clear if user code
is meant to inspect that or if it's only for libc internal use.

libstdc++-v3/ChangeLog:

	PR libstdc++/93421
	* src/c++11/chrono.cc [_GLIBCXX_USE_CLOCK_GETTIME_SYSCALL]
	(syscall_timespec): Define a type suitable for SYS_clock_gettime
	calls.
	(system_clock::now(), steady_clock::now()): Use syscall_timespec
	instead of timespec.
	* src/c++11/futex.cc (syscall_timespec): Define a type suitable
	for SYS_futex and SYS_clock_gettime calls.
	(relative_timespec): Use syscall_timespec instead of timespec.
	(__atomic_futex_unsigned_base::_M_futex_wait_until): Likewise.
	(__atomic_futex_unsigned_base::_M_futex_wait_until_steady):
	Likewise.

0 files changed, 0 insertions, 0 deletions