On 08/10/2020 04:57, Lukasz Majewski wrote:
> Hi Adhemerval,
> 
>> On 07/10/2020 11:25, Adhemerval Zanella wrote:
>>>
>>>
>>> On 07/10/2020 09:52, Adhemerval Zanella wrote:  
>>>>
>>>>
>>>> On 06/10/2020 06:48, Lukasz Majewski wrote:  
>>>>> Hi Adhemerval,
>>>>>  
>>>>>> A new struct __stat{64}_t64 type is added with the required
>>>>>> __timespec64 time definition.  Both non-LFS and LFS support were
>>>>>> done with an extra __NR_statx call plus a conversion to the new
>>>>>> __stat{64}_t64 type.  The statx call is done only for
>>>>>> architectures with support for 32-bit time_t ABI.
>>>>>>
>>>>>> Internally some extra routines to copy from/to struct stat{64}
>>>>>> to struct __stat{64} used on multiple implementations (stat,
>>>>>> fstat, lstat, and fstatat) are added on a extra file
>>>>>> (stat_t64_cp.c).  Aslo some extra routines to copy from statx to
>>>>>> __stat{64} is added on statx_cp.c.
>>>>>>
>>>>>> Checked with a build for all affected ABIs. I also checked on
>>>>>> x86_64, i686, powerpc, powerpc64le, sparcv9, sparc64, s390, and
>>>>>> s390x.  
>>>>>
>>>>> When do you plan to pull this patch set to -master?
>>>>> Those patches have been available for review on the mailing list
>>>>> for more than two months now.  
>>>>
>>>> Hi Lukasz, thanks to remind me. I will rebase against master and
>>>> run some regressions tests against some platforms and push it.
>>>>  
>>>
>>> One required change with the rebase is adapt the riscv32 ABI to
>>> exclude the __{f,l}xstat{at} symbol and replace with proper
>>> {f,l}stat ones. It is possible because the new ABI was added on
>>> current development branch, however one minor inconvenient is the
>>> toolchain need to be rebuild with a updated glibc branch to avoid
>>> linking failures with libstd++ (which uses __{f,l}xstat{at}).
>>>   
>>
>> Ok, I have ran the testsuite on x86_64, x32, i686, aarch64, armhf,
>> powerpc, powerpc64, powerpc64le, sparc64, sparcv9, s390x, and s390
>> without regression. I will just finish the testing on mips, mips64,
>> and alpha since they require some specific implementations.
>>
> 
> That would be a huge step forward.
> 
> According to list in the following commit message:
> https://github.com/lmajewski/y2038_glibc/commit/73215359e184d96b415e87b585a4396b5bd0936c

The mips testing caught an issue on where the "linux: Disentangle 
fstatat from fxstatat" patch uses INTERNAL_SYSCALL_CALL where
it should use INLINE_SYSCALL_CALL (which sets the errno).  I have
fixed and this only affects mips, so my testing should cover all
the affects architectures (I got access to a ia64 machine again
and I will run a regression test once I commit this to master).

> 
> Then I will send an RFC for enabling support for 64 bit time on
> eligible architectures.

There still some missing implementations I have on my local tree:

 1. wait3: it is a straightforward fix since it just calls __wait4_time64.
 2. ftime: we need to move it to a compatibility symbol, so there will
    be no need to add a time64 variant to support the deprecated symbol.
 3. futimesat: we need to remove the implementation on generic folder
    and handle UTIME_NOW and UTIME_OMIT correctly.
 4. recvvmsg/recvmsg: we need to handle ancillary data. I recently send
    patch that tries to handle it [1] [2] [3]. It is more in a RFC and
    I don't think it is strictly necessary.
 5. utmp/utmpx/lastlog: I also sent a fix to handle the 64-bit support
    on this [4]

I will send 1. 2. 3., since they are the easiest one to review.

[1] https://sourceware.org/pipermail/libc-alpha/2020-September/117484.html
[2] https://sourceware.org/pipermail/libc-alpha/2020-September/117485.html
[3] https://sourceware.org/pipermail/libc-alpha/2020-September/117486.html
[4] https://sourceware.org/pipermail/libc-alpha/2020-August/116850.html