• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 1195 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

AM3352: About SDK 8.2 release

AM3352: date command can't set the year 2039 in SDK8.2.

Naoto Uegaki
Intellectual 775 points
Part Number: AM3352

In the parent thread, it was mentioned that "SDK 8.2 uses Linux kernel 5.10. So I would expect that the Y2038 issue is resolved.".

I built SDK8.2 and boot it. Then I typed date command, but date command can't set the year 2039 as shown in the below.

root@mmc-rmu:~# date -s 203801010000
Fri Jan  1 00:00:00 UTC 2038
root@mmc-rmu:~# date -s 203901010000
date: invalid date '203901010000'

Though I checked the busybox's configuration file, "CONFIG_LINUX64=y" was defined.

uegaki@admine330-Precision-3520:~/ex1/rmu/tisdk8/build/arago-tmp-external-arm-glibc/work/armv7at2hf-neon-linux-gnueabi/busybox/1.31.1-r0.arago21.tisdk0/busybox-1.31.1$ grep CONFIG_LINUX .config
CONFIG_LINUXRC=y
CONFIG_LINUX32=y
CONFIG_LINUX64=y

Why did date command failed when 2039 is specified ?
Could you teach me how to solve this issue ?

  • 0
    TI__Guru 58915 points

    Hello Naoto,

    We'll get back to you next week.

    Thanks for your patience.

    Regards,

    Jianzhong

  • 0 in reply to Jianzhong Xu
    TI__Guru** 100960 points

    Hello Naoto,

    Interesting. I was under the impression that this should work out of the box, but I am seeing the same behavior as you:

    root@am335x-evm:~# uname -a
Linux am335x-evm 5.10.100-g7a7a3af903 #1 PREEMPT Sat May 14 22:36:58 UTC 2022 armv7l armv7l armv7l GNU/Linux
root@am335x-evm:~# date --date="01/01/2039"
date: invalid date '01/01/2039'
root@am335x-evm:~#
date --date="01/01/2038"
Fri Jan  1 00:00:00 UTC 2038

    Let me do some background research and get back to you. Please ping the thread if I have not responded by early next week.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Guru** 100960 points

    Hello Naoto,

    I am having some discussion with the developers, but I do not have any big updates yet. Please ping the thread if I have not replied by the end of the week.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 775 points

    Hello,

    Thank you for reply.

    By the way, I think that the cause of this issue is time_t was compiled as 32bit because this is default settings of glibc. There seems to be two ways to solve this issue. One is to use "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" options for glibc to compile time_t as 64bit. This requires gcc-arm-11.2 (can't use gcc-arm-9.2). Another is to use musl instead of glibc because musl compiles time_t as 64bit by default setting.

    So, I tried to use musl. Though I added TCLIBC = "musl" in local.conf, bitbake building was failed.
    Now, I'm trying to use gcc-arm-11.2 and "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64". But I met some errors, so I'm investigating. If I have some updates, I'll inform you that.

  • 0 in reply to Naoto Uegaki
    TI__Guru** 100960 points

    Hello Naoto,

    No major updates on this side. For future readers, this stackoverflow answer was helpful: https://stackoverflow.com/a/60709400/4623956

    My understanding of https://lkml.org/lkml/2020/1/29/355?anz=web and https://lwn.net/Articles/776435/ is that Linux kernel 5.10 itself should be y2038 safe. However, applications built on top of the Linux kernel may still use 32 bit timers, so that is where customers need to be conscious of y2038. I am double-checking this with the developers.

    Your observations look correct as far as I can tell. The fact that glibc is NOT y2038 compliant by default (i.e., the default is still 32 bit time, so you need to specifically tell it to compile time_t as 64 bit) is important to note.

    Where did you find information about gcc-arm versions working or not working with y2038 fixes?

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 775 points

    Hello,

    > Where did you find information about gcc-arm versions working or not working with y2038 fixes?
    Because "_TIME_BITS" string can be found in gcc-arm-11.2, and can not be found in gcc-arm-10.3 as shown in the below.

    uegaki@sdk1:~/ex1/rmu$ grep -r -e "\b_TIME_BITS\b" gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/include/features-time64.h:#if defined _TIME_BITS
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/include/features-time64.h:# if _TIME_BITS == 64
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/include/features-time64.h:#   error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/include/features-time64.h:# elif _TIME_BITS == 32
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/include/features-time64.h:#   error "_TIME_BITS=32 is not compatible with __TIMESIZE > 32"
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/include/features-time64.h:#  error Invalid _TIME_BITS value (can only be 32 or 64-bit)
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/share/info/libc.info-1: -- Macro: _TIME_BITS
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/share/info/libc.info-1:       1. If ‘_TIME_BITS’ is undefined, the bit size of ‘time_t’ is
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/share/info/libc.info-1:       2. If ‘_TIME_BITS’ is defined to be 64, ‘time_t’ is defined to be
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/share/info/libc.info-1:       3. If ‘_TIME_BITS’ is defined to be 32, ‘time_t’ is defined to be
gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/share/info/libc.info-1:     ‘_TIME_BITS=64’ can be defined only when ‘_FILE_OFFSET_BITS=64’ is
バイナリファイル gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc/usr/share/info/libc.info-17 に一致しました
uegaki@sdk1:~/ex1/rmu$ 
uegaki@sdk1:~/ex1/rmu$ grep -r -e "\b_TIME_BITS\b" gcc-arm-10.3-2021.07-x86_64-arm-none-linux-gnueabihf
uegaki@sdk1:~/ex1/rmu$