Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1.1: Type: text/plain, Size: 3254 bytes --]

Hi Arnd,

> On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski <lukma@denx.de> wrote:
> > > 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> 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').  
> 
> I'd actually consider intentionally breaking this for a Debian
> bootstrap, at least initially, so that any application that
> accidentally gets built without -D_TIME_BITS=64 runs into a build or
> link failure.

I do see two approaches here:

1. In glibc:

When -D_TIME_BITS=64 is set - redirections are enabled for syscall
wrappers; for example __clock_settime64 is used instead of
__clock_settime (e.g. sysdeps/unix/sysv/linux/clock_settime).

The latter is guarded by #ifdef __TIMESIZE != 64 so we could change
mechanically that __clock_settime returns -1 and sets errno to -ENOTSUPP


2. In kernel - return -ENOTSUPP when clock_settime syscall instead of
clock_settime64 is invoked.

> 
> > - 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.  
> 
> Ok.
> 
> > > > - 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]?  
> 
> Not sure, maybe Helmut has some references.
> 
> > > 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?  
> 
> I think this is currently in the planning stage, but once patches
> are available, they would be posted to the ltp mailing list. Viresh
> should have more details on this.
> 
>        Arnd




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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc