Re: [RFC 0/7] y2038: clock_settime rework to be Y2038 safe on 32bit systems

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 27 Mar 2019, Lukasz Majewski wrote:

>   -- The Y2038 support is enabled only when _ALL_ syscalls/functions are Y2038 ready

Yes, that's correct.  All the header changes to support _TIME_BITS=64, new 
symbol versions and corresponding changes to ABI baselines should be made 
at once.

> - I've read that clock_* functions were moved from librt to glibc - what 
> was the motivation behind this move?

librt depends on libpthread.  Linking against libpthread causes some 
multithreaded code paths to be used, so slowing down programs even if they 
are single-threaded.  The clock_* functions are commonly usable without 
threads, so it makes sense to have them in libc.

(Whether we should somehow avoid the slowdown from pthreads functions 
being present, and have everything in libc, is a separate question.)

> Why to we have compatibility code in the rt/* for
> clock_settime() if the _real_ support is in time/* ?	

We have to stay compatible with existing programs built with older glibc 
versions that expect to get functions such as clock_settime from librt.so.

When making changes in this area, running the glibc testsuite for a range 
of architectures is helpful - the ABI tests and linknamespace tests will 
catch some possible bugs.  But you should also manually inspect the 
clock_* symbols exported from librt.so to make sure they look the same 
before and after the change (as opposed to any GLIBC_PRIVATE __clock_* 
exports, where changes are OK as long as the symbols exported match the 
ones used in other libraries).

For example, the ABI tests do not verify whether a given symbol is a 
compat symbol or not.  If you look at the output of objdump --dynamic-syms 
on librt.so you'll see e.g.

0000000000004dc0 g   iD  .text  0000000000000008 (GLIBC_2.2.5) clock_gettime

where the parentheses around the symbol version indicate it's a compat 
symbol - so you should verify that remains the same before and after the 
patch.  The 'i' in 'iD' indicates an IFUNC because that's how the 
redirection from librt to libc versions works, so make sure it remains an 
IFUNC after the changes (on architectures supporting IFUNCs; on others, it 
should remain a wrapper).  And do this verification for both 32-bit and 
64-bit architectures.

-- 
Joseph S. Myers
joseph@codesourcery.com