问题
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 offutex()
andseccomp()
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