[PATCH 1/3] y2038: linux: Provide __futimes64 implementation

[Vineet Gupta]

On 7/7/20 12:21 AM, Lukasz Majewski wrote:
>> ARC is 32-bit + TIMESIZE==64 but the new code is not getting built
>> (instead generic variant is). How do I override the generic fiel to
>> be built instead ?
> The futimes.c from sysdeps/unix/sysv/linux/ shall be built. 
> 
> The futimes.c is defined in following locations:
> y2038-glibc/misc
> y2038-glibc/sysdeps/unix/sysv/linux
> y2038-glibc/sysdeps/mach/hurd
> 
> The first one is a stub. The last one is for hurd.
> ARC shall use the middle one as well.

It seems I mixed up the various *utime* files.
Following are currently building for ARC

sysdeps/unix/sysv/linux/generic/futimesat.c
sysdeps/unix/sysv/linux/generic/utimes.c    #2

sysdeps/unix/sysv/linux/futimes.c
sysdeps/unix/sysv/linux/futimens.c
sysdeps/unix/sysv/linux/utimensat.c

The issue is generic/utimes.c

Is that the right file to build. If yes then it needs fixing as it expects
__NR_utimensat (and thus require the aliasing hack in ARC sysdep.h)

#define __NR_utimensat		__NR_utimensat_time6

P.S. I know glibc wiki has a bunch of pages (from Arnd?) for the y2038 support.
Are there other (newer) docs which explain the whole song and dance or is it the
usual RTFC.

> When I'm in doubt (or when for example code is auto generated to wrap a
> syscall) I do use
> https://github.com/lmajewski/meta-y2038/blob/master/README
> 
> with gdb to check which function is called. Maybe it would help you too?

Yeah. I typically use build logs to see which exact file is built and then objdump
to corroborate.