Hi Arnd, > On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski <lukma@xxxxxxx> wrote: > > > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@xxxxxxx> > > > wrote: > > > > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski > > > > > <lukma@xxxxxxx> 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@xxxxxxx
Attachment:
pgpYBoV3ZAoCu.pgp
Description: OpenPGP digital signature
_______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
