[RFC v3 04/23] sysdeps/clock_gettime: Use clock_gettime64 if avaliable
Arnd Bergmann
arnd@arndb.de
Thu Jul 18 07:39:00 GMT 2019
On Wed, Jul 17, 2019 at 5:16 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> The real question is whether vDSO and its constituent functions are
> optional from a userspace ABI perspective. If they are mandatory, we
> can go straight to the 32-bit vDSO, and, possibly after that, the 32-bit
> system call. Instead of the vDSO implementation, we would install our
> own emulation in the function pointer. If the 64-bit vDSO is optional,
> we would likely have to probe the 64-bit system call once, to keep
> things sane and simple, and switch between the system call wrapper and
> the fallback implementation (same as for the mandatory vDSO case).
Good question. I assumed that they would be optional because:
- Half the Linux architectures don't have any vdso support at all
- arm64 traditionally has no support for 32-bit vdso (added in
linux-5.3), and still only contains it if an arm32 toolchain is available
at kernel build time and we use gcc rather than clang (to be fixed
in the future).
- I assumed that all libc implementations already need a fallback
to plain syscalls to run on older kernels even for architectures that
have it today.
- The recent rewrite of the vdso implementation in the kernel was not
ready for 5.1, so no architecture has clock_gettime64() so far, but
a lot of them clock_gettime()
I agree that assuming a vdso clock_gettime64() to be present on
all architectures would make this much easier for you, but I'd
still hope we can find a way to avoid truncating the times if you
do that.
I have two ideas for how that could be done:
- When building for a minimum kernel version of 5.1, don't
fall back to __vdso_clock_gettime() or syscall(__NR_clock_gettime)
but use the slow path for __clock_gettime64() if the vdso doesn't
work.
- if __vdso_clock_gettime64() is unavailable and __vdso_clock_gettime()
returns negative seconds, fall back to syscall(__NR_clock_gettime).
Would either of those meet your requirements?
Arnd
More information about the Libc-alpha
mailing list