This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC v3 04/23] sysdeps/clock_gettime: Use clock_gettime64 if avaliable


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]