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

[Lukasz Majewski <lukma at denx dot de>]

Hi Joseph,

> 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.

Ok.

So the work plan is as follows:

1. Rewrite relevant syscalls (for sysdeps/unix/sysv/linux - Linux) to
use

__clock_settime64 () 
{

}

#if TIMESIZE != 64

clock_settime ()
{
	...
	__clock_settime64();
	...
}
#endif

Those shouldn't introduce make xcheck/check regressions.

And can be added syscall by syscall - i.e.
clock_{settime|gettime|nanosleep|getres}

In this step the internal glibc explicit 64bit types shall be
introduced (struct __timespec64, __time64_t, struct __timeval64, etc).


2. When _TIME_BITS=64 patch is introduced:

This shall be done in a single patch (!), which would include:
redirection of functions, manual entry, __USE_TIME_BITS64 definition
etc.

To reduce the overwhelming patch size from point 2 - tests shall be
added in point 1 (so I only then add -D_TIME_BITS=64 switch to be
compiled in).

> 
> > - 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.
> 

And this explains why this RFC causes following regression:

FAIL: rt/check-abi-librt
	^^^ - I do not export clock_settime anymore for librt

FAIL: time/check-wrapper-headers
	^^^ What are the "wrapper-headers"? Is this a different name
	for "installed" headers in glibc terms ?

Summary of test results:
      9 FAIL
   6048 PASS
     21 UNSUPPORTED
     17 XFAIL
      2 XPASS



If I may ask:

What is the workflow/setup for build-many-glibcs.py ?

Is it 
./src/glibc/scripts/build-many-glibcs.py -j8 . checkout

and then 
./src/glibc/scripts/build-many-glibcs.py -j8 . bot


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

Attachment: pgpGNXPSFzKdf.pgp
Description: OpenPGP digital signature