[RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation
Joseph Myers
joseph@codesourcery.com
Mon Jul 8 10:49:00 GMT 2019
On Tue, 25 Jun 2019, Arnd Bergmann wrote:
> Your __clock_settime however does the reverse: you have an application
> that calls clock_settime(), the alias redirects that to __clock_settime(),
> and that converts it into the 64-bit structure and passes it into
> __clock_settime64(), which then calls the time64 syscall before falling
> back to calling the time32 syscall.
Yes, that's exactly what it's meant to do.
My position is as stated at
<https://sourceware.org/ml/libc-alpha/2018-12/msg00136.html>. Duplicating
nontrivial functions at the source-code level for 32-bit / 64-bit time is
unmaintainable; duplicating them at the binary level is unreasonable bloat
(for avoidance of doubt, this is a sustained objection). Thus calls to
pthread_mutex_timedlock for 32-bit time must end up using syscalls with
64-bit time, because implementation approaches other than thin wrappers
round the 64-bit version are unreasonable.
I think the appropriate definition of a trivial interface for 32-bit time,
for which it's OK not to use a thin wrapper, is a syscall wrapper
generated through syscalls.list; anything requiring actual C code to
implement the function should be a thin wrapper round the version using
64-bit time rather than having a variant that just tries to use the 32-bit
syscall without attempting the 64-bit one.
As I said in <https://sourceware.org/ml/libc-alpha/2018-12/msg00144.html>,
the choice of syscalls behind a function in glibc has never been a stable
interface in glibc, and I don't think it ever reasonably can be a stable
interface; you have to use the dynamic symbol table to identify whether a
binary is using interfaces for 32-bit time, rather than basing things on
what syscalls it uses at runtime.
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Libc-alpha
mailing list