On Wed, 2022-11-30 at 14:36 +0100, Lukasz Majewski wrote: > > On Wed, 2022-11-30 at 09:07 +0100, Alexander Kanavin wrote: > > > On Tue, 29 Nov 2022 at 16:45, Stephen Jolley > > > <sjolley.yp...@gmail.com> wrote: > > > > We’d welcome a proposal/series on how to move forward with the > > > > Y2038 work for 32 bit platforms. > > > > > > I have the following proposal: > > > > > > 1. A branch is made where: > > > a. "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" is enabled globally. > > > b. qemu is always started with "-rtc base=2040-01-01", simulating > > > Y2038 actually occurring. > > > c. an additional runtime test verifies that both RTC clock and > > > system clock report 2040. > > > > > > 2. This branch is run through a-full on the autobuilder. Any > > > uncovered issues are filed as bugs. > > > > > > 3. Once *all* of the bugs are addressed, repeat point 2. > > > > > > 4. Once there are no more open bugs, 1a is merged into master. > > > > > > Any fatal flaws in the plan? > > > > Others have made some good comments. My thoughts: > > > > * We need to add some runtime tests to oeqa for this (in addition to > > the ptests) > > > > * We need to have a 32 bit ptest run on the autobuilder (qemux86 > > should work, not sure we can make qemuarm fast). Whether this is > > manually triggered, not sure. We could have a smaller set of ptests > > to run for it? > > Y2038 ptests maybe? > > Here is the list of integrated tests to ptests: > https://github.com/lmajewski/y2038-tests
Perhaps, yes. > > * Could we optionally disable some of the glibc 32 bit function calls > > to ensure they're not being used? > > Could you be more specific here? Would you like to disable some > syscalls? I'm meaning disabling the 32 bit glibc time functions. > > We don't really want to diverge from > > upstream glibc much though. > > Could you be more specific here? The glibc now supports the whole set > of syscalls as of 2.34 version? > > To enable them one needs to pass -D_TIME_BITS=64 flag when compiling > programs. > > This is now the official glibc ABI. Right, but the 32 bit time functions/symbols are still available for older binaries. My point is that anything using those older functions is likely in need of attention so for Yocto Project/OE usage, identifying those would be helpful. If we were to disable them, that would make such usage very obvious. > > > The reason for that is that if someone has > > existing binaries, there could be problems using them after the > > change. > > The binary shall work without issues on glibc 2.34+ and 5.10+ kernel > without issues. Not necessarily. If it were a binary library, compiled with 32 bit time_t, new binaries using it would use a different sized field. > The only problem happens when new binaries with 64 bit time support are > run on glibc or kernel not supporting 64 bit time. That is definitely not the only problem. Some of the problems are unlikely but we do need to consider them. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58679): https://lists.yoctoproject.org/g/yocto/message/58679 Mute This Topic: https://lists.yoctoproject.org/mt/95357621/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
