Hi Arnd,

> On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@denx.de>
> wrote:
> > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski <lukma@denx.de>
> > >
> > > Would it be possible to take a snapshot of your glibc tree  
> >
> > The description of the status of Y2038 supporting glibc on ARM 32
> > can be found here [1].
> >
> > The most recent patches for Y2038 supporting glibc can be always
> > found in the 'y2038_edge' branch [2].  
> 
> Ok.
> 
> > > and start testing this out with debian-rebootstrap [1]?  
> >
> > I've been using OE/Yocto for testing as it allows building glibc
> > sources for x86_64, x86, x86-x32, arm32 (probably also for ppc32 and
> > mips - but not tested).
> >...
> > However, I did not yet tried debian-rebootstrap. I will look if this
> > can be reused as well.  
> 
> The reason I'm asking about debian-rebootstrap is less about testing
> glibc itself than about testing the rest of user space to figure out
> better what needs to be done when rebuilding with _TIME_BITS=64, and
> to start fixing more upstream packages, with the hope of having enough
> of it done in time for the Debian 11 release.

Ok. I see. Thanks for the information.

Validating the packages was one of the reasons to move from some custom
made test images/setup to Yocto/OE (as it is very close to customers
needs).

> 
> > > Are there any glibc issues that prevent it from working
> > > correctly,  
> >
> > I think that the glibc wrappers for most important syscalls are now
> > converted.
> >
> > What is missing:
> >
> > - NTPL (threads)
> > - stat  
> 
> Do you mean that code using these will fail to work correctly with
> -D_TIME_BITS=64 at the moment, or that the interfaces are there
> but they are not y2038 safe? 

For ARM32 (branch [2]):

- Without -D_TIME_BITS=64 defined during compilation (as we do have
  now) the glibc is fully functional, but when you set date after
  03:14:08 UTC on 19.01.2038 you will see the date reset (to 1901) in
  the user space programs (after calling e.g. 'date').

- With -D_TIME_BITS=64 set during compilation - and using branch [2] -
  syscalls listed in [1] will provide correct date after Y2038 32 bit
  overflow. Other (i.e. not converted ones) will use overflow date (1901
  year). The glibc will also be fully functional up till Y2038 overflow.

> Without pthreads or stat, we probably
> wouldn't get too far in rebootstrap, but if the interfaces are there
> and mostly work, then we don't need to rely on them being
> y2038-safe just yet.

According to my above statement the second assumption is correct.

> An obvious next step would be to run the
> resulting code with the RTC set 20 years ahead, and that requires
> it all to work.

Yes. This is what I do for the test setup [3]. I do use
clock_settime syscall (now it is working correctly) or just 'date'
from user space.

> 
> > - In-glibc test coverage when -D_TIME_BITS=64 is used. I do have
> >   some basic tests [4], but this may be not enough.  
> 
> This is probably something where debian-rebootstrap could help,
> as building and testing more user space packages will excercise
> additional code paths in glibc as well. 

Yes this _could_ help. Do you have any tutorial/howto similar to one
from [4]?

I also think that some tests from debian-rebootstrap could be moved to
glibc test framework (test suite). For example tests for
clock_settime/gettime/nanosleep/ etc. In that way the
glibc-many-build.py would run those tests for all supported ports.

Then the debian-rebootstrap could test for more sophisticated bugs
(like dependencies between syscalls, etc).

> There is also some work
> in Linaro to ensure that LTP tests the low-level syscall interfaces
> in both the time32 and time64 variants.

Interesting. Is this work now publicly available?


> 
>       Arnd

Links: 

[1] -
https://github.com/lmajewski/y2038_glibc/commit/4f72f695d1ac428fe945cd7d5e95770180d4a7c1
[2] - https://github.com/lmajewski/y2038_glibc/commits/y2038_edge
[3] - https://github.com/lmajewski/y2038-tests
[4] - https://github.com/lmajewski/meta-y2038/blob/master/README

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