Re: [PATCH 00/25] Change time_t and clock_t to 64 bit

Joseph S. Myers
2014-05-19T14:47:14Z

On Mon, 19 May 2014, Arnd Bergmann wrote:

> I'm mostly worried about the embedded use case, which at least for time_t
> would have to build everything the new way as soon as possible. For
> desktop and server systems, doing a slow migration to catch the bugs
> and never introduce regressions in the field makes a lot of sense,
> but when someone today wants to build an embedded system, they already
> build everything from source, and it's more important to find all
> the bugs now (ideally at compile time) than to have a chance of hitting
> a subtle issue 24 years ago on today's build.
>
> For that, it would be nice to even build a glibc that has no backwards
> compatibility interfaces for 32-bit time_t at all.

Building glibc without compatibility interfaces is --enable-oldest-abi (to
disable ABIs obsoleted before a given point, so that if the 32-bit time_t
interfaces are obsoleted and no longer available for new builds then it
would disable them) - but that's been bitrotten for years
<https://sourceware.org/bugzilla/show_bug.cgi?id=6652> and there is
consensus to remove it if anyone sends a patch. (Similarly,
--disable-versioning support was removed. The sort of really tiny
embedded systems for which that sort of thing is relevant as space
reduction no longer seem so relevant to glibc; there has been no interest
in merging option group support from EGLIBC to glibc now EGLIBC
development has been discontinued.)

Now, when the motivation is not space reduction but ensuring nothing is
there that will break in 2038 (unless it's doing dubious things like
storing a time_t value in an int or long in the application - something a
reasonably stupid static analysis should be able to detect), you could
always identify the (symbol, version) pairs for a given architecture that
use 32-bit time_t and develop a tool that checks for binaries using
problem symbols. (Of course, that won't help with ioctls.) Or put a
small patch in the headers to force _TIME_BITS=64 and not allow an
override with _TIME_BITS=32. And if the kernel had a config option to
disable all the old interfaces, that would make problem binaries break now
rather than in 2038.

> > > I don't know why timespec on x32 uses 'long tv_nsec', it does seem
> > > problematic.
> >
> > Yes, we have a glibc bug
> > <https://sourceware.org/bugzilla/show_bug.cgi?id=16437> about the glibc
> > definition (64-bit tv_nsec in x32 userspace to match the kernel's 64-bit
> > "long") being nonconforming, but without the kernel treating upper bits as
> > padding, fixing glibc requires wrappers that copy the value and clear the
> > upper bits.
>
> Ok. There is also work going on to have an x32-like ABI for ARM64, and
> that will likely have to support big-endian as well, so then it's not
> just about clearing the padding bits, but also having them in the right
> place.

Yes, I see no problem with putting the padding bits in the right place so
that when the kernel is passing struct timespec values *to* userspace, it
can just fill in the native 64-bit structure and have it automatically be
correct when interpreted as a 32-bit structure with padding (which the
kernel will have zeroed implicitly) on tv_nsec.

--
Joseph S. Myers
joseph@codesourcery.com