This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi Alistair, > On Fri, Jan 17, 2020 at 9:14 PM Lukasz Majewski <lukma@denx.de> wrote: > > > > Hi Alistair, > > > > > On Thu, Jan 16, 2020 at 11:34 PM Lukasz Majewski <lukma@denx.de> > > > wrote: > > > > > > > > Hi Alistair, Joseph > > > > > > > > > On Thu, Jan 16, 2020 at 11:21 AM Joseph Myers > > > > > <joseph@codesourcery.com> wrote: > > > > > > > > > > > > On Thu, 16 Jan 2020, Alistair Francis wrote: > > > > > > > > > > > > > > To allow it this syscall wrapper shall be converted > > > > > > > > (written) in the same way as e.g: > > > > > > > > > > > > > > > > ./sysdeps/unix/sysv/linux/clock_settime.c > > > > > > > > > > > > > > > > (the same issue is with getitimer). > > > > > > > > > > > > > > > > Then only redirection when __USE_TIME_BITS64 is set are > > > > > > > > needed to use __setitimer64/__getitimer64 on Y2038 safe > > > > > > > > systems. > > > > > > > > > > > > > > I'm not sure what you mean here. > > > > > > > > > > > > > > There is no setitimer64/getitimer64 syscall so we need to > > > > > > > make sure we pass a 32-bit time_t here. If __TIMESIZE == > > > > > > > 32 then we don't need any changes and can just directly > > > > > > > make the syscall (as we do in this patch). The conversion > > > > > > > is only required if __TIMESIZE == 64 as we need to > > > > > > > convert to/from a 32-bit time_t. > > > > > > > > > > > > This is a point about the general structure and goals of the > > > > > > Y2038 work. > > > > > > > > > > > > We want to end up at a point where, on systems where time_t > > > > > > is currently 32-bit, you can build with -D_TIME_BITS=64 and > > > > > > get 64-bit time_t instead. That means that all time-related > > > > > > functions, including getitimer and setitimer, will, on such > > > > > > systems, need to have two implementations in glibc, one > > > > > > using 64-bit times and one using 32-bit times. > > > > > > > > > > I'm still confused. If we build with -D_TIME_BITS=64 does that > > > > > then mean that __TIMESIZE == 64 ? > > > > > > > > > > In which case the user exposed time_t is 64-bit and these > > > > > calls will take a 64-bit time_t and convert it to/from a > > > > > 32-bit time_t to pass to the kernel. The user will only ever > > > > > use/see a 64-bit time_t. > > > > > > > > > > > > The implementation structure generally being used is that > > > > > > the main implementation has an interface using 64-bit times > > > > > > (even if it ends up using syscalls with 32-bit times) and > > > > > > the one using 32-bit times is a thin > > > > > > > > > > Isn't that what is happening here when __TIMESIZE == 64 ? > > > > > > > > > > > wrapper around it (if time_t is already 64-bit, the second > > > > > > implementation does not exist and some macros ensure the > > > > > > first implementation keeps its existing name). Once all > > > > > > functions have been moved to that structure, we can set > > > > > > things up so that all those 64-bit functions are exported > > > > > > from glibc and add _TIME_BITS support in the headers. > > > > > > > > > > Ah, do you mean that glibc should expose a 64-bit time_t > > > > > version if __TIMESIZE == 32? > > > > > > > > Yes, exactly. > > > > > > > > Currently 32 bit ARM (__WORDSIZE == 32 && __TIMESIZE == 32) use > > > > 32 bit time_t. However, after compiling the source code with > > > > -D_TIME_BITS=64 the time_t will become 64 bit. > > > > > > > > Please find example setup for tests_y2038: > > > > https://github.com/lmajewski/y2038-tests/blob/master/Makefile#L25 > > > > (Two binaries are build from the same sources - one is Y2038 > > > > safe and other is not). > > > > > > > > The notable difference between the new RV32 port and existing > > > > ARM32 is that for new ports (i.e. RV32) the __TIMESIZE = 64 is > > > > set from the outset. > > > > For the latter (ARM32) the __TIMESIZE = 32 is kept and IIRC we > > > > will NOT update it to __TIMESIZE = 64 anytime soon. Instead, in > > > > exported headers _TIME_BITS=64 will be set by default (approach > > > > similar to the one for _FILE_OFFSET_BITS=64). > > > > > > Doesn't that mean that I can fix this all by just using if > > > _TIME_BITS == 64 instead of __TIMESIZE? > > > > Unfortunately, not. The _TIME_BITS define affects _exported_ glibc > > headers. It sets __USE_TIME_BITS64, which shall NOT be used in glibc > > internals: > > https://github.com/lmajewski/y2038_glibc/commit/319c24507974fecdffe5182d310289b2a4cb9122#diff-a5ab6c74681eaf0569ed54f6bf0d7978R391 > > > > > > Instead, the glibc shall be prepared for handling those syscalls > > correctly in both cases - when _TIME_BITS == 64 (Y2038 safe) is > > defined or not during the compilation. > > > > > > > > > > > > > Joseph, am I right? > > > > > > > > > So even __TIMESIZE == 32 systems can call a 64-bit > > > > > time_t version (even if the syscall ends up being 32-bit). > > > > > > > > +1 > > > > > > Even if time_t is 64-bit you can't pass a value larger then > > > 32-bits to these functions as they get converted back to a 32-bit > > > value for the kernel syscall. > > > > The problem is with consistency: > > > > 1. Internally glibc is going to replace time_t (which may be 32 bit) > > with __time64_t (as it is done indirectly with introduction of > > struct __timespec64, etc). In that way glibc will be itself Y2038 > > safe no matter of __TIMESIZE value (32, 64 bit). > > > > 2. The functions with 64 suffix (i.e. __getitimer64, __settime64) > > > > e.g.: > > > > int > > __getitimer64 (__itimer_which_t which, struct __itimerval64 > > *curr_value) > > > > Will use struct __itimerval64, which will always support 64 bit time > > (the same situation as with struct __itimerspec64). > > > > > > Afterwards, I will define redirection for it in the exported > > headers - like for example here (for timerspec_get): > > https://github.com/lmajewski/y2038_glibc/commit/9844cb7beb854e21bbdc595398627777b6155c27#diff-07934c1fe09f0e6357413e138856c786R320 > > > > This redirection will force usage of __gettimer64 on ARM32 bit > > (__TIMESIZE==32 && __WORDSIZE==32) when -D_TIME_BITS=64 is set > > during compilation. > > > > (I'm now finishing patches to introduce struct __timeval64 to glibc) > > > > > > > > > > > > > > > Please find example conversion code for timespec_get conversion: > > > > https://patchwork.ozlabs.org/patch/1224222/ > > > > > > > > it internally uses __clock_gettime64, which uses 64 bit time no > > > > matter on which architecture it runs (even with > > > > __TIMESIZE==32). > > > > > > In this case though the syscall is always 32-bit, so I'm not sure > > > if there is a huge advantage here. > > > > The advantage is that the consistency of function conversion will be > > preserved. The __gettimer64 function will be used, even though we > > will use 32 bit syscalls and when kernel (maybe?) introduce 64 bit > > syscalls we will be ready. > > > > > > > > I don't see a point of converting this function to take a 64-bit > > > value if time_t is 32-bit as that doesn't give you anything. > > > > time_t may be 32 bit or 64 on the Y2038 safe systems. It depends on > > adding -D_TIME_BITS=64 during compilation. > > > > > It does seem > > > worth changing the #if to check _TIME_BITS == 64 instead of > > > __TIMESIZE though. > > > > As I've stated above - the _TIME_BITS (and __USE_TIME_BITS64) are > > supposed to be "visible" in the glibc exported headers. > > The __USE_TIME_BITS64 flag enables redirection for the syscalls: > > https://github.com/lmajewski/y2038_glibc/commit/319c24507974fecdffe5182d310289b2a4cb9122#diff-8bdb75c23cf534160b06f2dc2183e971R67 > > > > On the glibc side one shall have time functions converted to: > > https://github.com/lmajewski/y2038_glibc/commit/6367f6e061c5184b39cf7fff07ffcf8b569d765e#diff-a8bb3b17dcb4b2b40deba97323563301R33 > > > > Thanks for clarifying that. I think I understand now. > > So basically follow the other implementations (or the link directly > above) and add a __getitimer64/__setitimer64 function and a wrapper > __getitimer/__setitimer for the current 32-bit time_t. Yes, exactly. :-) > > Alistair > > > > > > > > > > > Alistair > > > > > > > > > > > Please also refer to the branch, which moves 32 bit ports > > > > closer to being Y2038 safe: > > > > > > > > https://github.com/lmajewski/y2038_glibc/commits/glibc_timespec_get-conversion-v1 > > > > > > > > > > > > > > Alistair > > > > > > > > > > > > > > > > > -- > > > > > > Joseph S. Myers > > > > > > joseph@codesourcery.com > > > > > > > > > > > > > > > > > > > > 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 > > > > 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 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:
pgps1PxmRm4pc.pgp
Description: OpenPGP digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |