64-bit time_t in Linux Kernel

£可爱£侵袭症+ 提交于 2021-01-28 06:12:05

问题


I have compiled kernel 3.19.1 but still have a problem with time_t. Just a simple program with cout << sizeof (time_t); gives size of 4 bytes, not 8 bytes as was my intention.

Should I switch on a particular option during make menuconfig?


回答1:


Currently time_t is just long in kernel: see __kernel_time_t type definition. So if long type on your CPU is 32-bit long, time_t also is 32-bit long. Basically, if you have 32-bit CPU -- long type on your system is also 32-bit long. If you have 64-bit CPU -- long type will be 64-bit long.

If you need your own 64-bit type -- just use long long. If you want kernel time API to work with 64-bit long type as time_t -- it's a little harder (implies changing kernel sources). For example take a look here. Also you may be interested in reading next links:

[1] patchset: "Change time_t and clock_t to 64 bit"

[2] Is there any way to get 64-bit time_t in 32-bit program in Linux

[3] What is ultimately a time_t typedef to?


UPDATE

Regarding building issues (with __divdi3 etc.) after changing time_t to long long.

Now that you have changed time_t size to 64-bits, any code that uses time_t will try to use 64-bit operations. __divdi3 means: division operation on double integers. 3 stands for count of operands (like 1 = 2 / 3). See this for details. So this operation obviously hasn't implemented for your platform. You should either implement it by yourself (in kernel code) or use implementation from gcc somehow. Next links should help you:

[1] __udivdi3 undefined. Howto find code?

[2] divdi3 division used for long long by gcc on x86

[3] Where to find udivdi3 and umoddi3 in gcc?




回答2:


64-bit time support on 32-bit Linux was first introduced in the 5.1 kernel so if you're older than that, sorry. Because changing the return type of the old system calls breaks old applications, new *time64 syscalls had to be added instead. Check this table and you'll see that those syscalls are only available on 32-bit platforms.

Now if you're writing code for 32-bit systems you can call clock_gettime64 directly (from inline assembly, or from C with syscall() function) to get the current time. However after that you're completely on your own. For full userspace support you must be on Linux 5.6 or higher along with musl 1.2+ or glibc 2.32+. Just rebuild your code and time_t will become 64-bit long

  • All user space must be compiled with a 64-bit time_t, which will be supported in the coming musl-1.2 and glibc-2.32 releases, along with installed kernel headers from linux-5.6 or higher.

  • Applications that use the system call interfaces directly need to be ported to use the time64 syscalls added in linux-5.1 in place of the existing system calls. This impacts most users of futex() and seccomp() as well as programming languages that have their own runtime environment not based on libc.

https://lkml.org/lkml/2020/1/29/355?anz=web

For more information read

  • Approaching the kernel year-2038 end game
  • Discussion on how to solve Y2038 problem: 2038 is closer than it seems
  • 64-bit time symbol handling in the GNU C Library
  • glibc Y2038 Proofness Design
  • Change time_t and clock_t to 64 bit


来源:https://stackoverflow.com/questions/29085124/64-bit-time-t-in-linux-kernel

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!