vdso clock_gettime and time64

[Rich Felker <dalias@libc.org>]

One looming thing that folks probably aren't going to like about
switching to 64-bit time_t is losing the vdso clock_gettime on old
kernels. Instead of a function call in userspace, you get *two*
syscalls, the first (time64) one failing, every time you call
clock_gettime. Of course the problem goes away immediately if you have
a time64-capable kernel providing the time64 vdso function.

Is this a problem, and if so, what can be done about it?

Obviously it's possible to grab the legacy time32 vdso symbol and wrap
it with a function to translate. Aside from being more code and
complexity, the problem with this is that it precludes the ability to
checkpoint/resume long-lived processes from an old kernel to a new one
with time64, which might become a real need in some environments where
people realize they've screwed up at the last minute as Y2038 is
approaching.

What might make sense is checking that the tv_sec obtained from the
legacy time32 vdso function is non-negative, and disabling it
permanently if the check fails, reverting to syscalls. This would be
safe for any process that makes at least one call to clock_gettime
before ~2106 after migration.

Alternatively we could figure the burden is on someone performing such
checkpoint/resume to figure out how to patch process images to disable
the no-longer-usable vdso, and that musl has no role in making it
work. (Note that this is something of a position advocating for tools
poking at internals, which I don't like...)

The cleanest course of action is of course just not using the 32-bit
vdso at all, and accepting that clock_gettime will be slower until you
get a Y2038-safe kernel.

Thoughts?

Rich