[PATCH 15/16] linux: Add {f}stat{at} y2038 support

Adhemerval Zanella adhemerval.zanella@linaro.org
Wed Oct 7 21:01:58 GMT 2020



On 07/10/2020 17:20, Lukasz Majewski wrote:
> Hi Adhemerval,
> 
>> 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}).
>>
> 
> Does it mean that we would need to run glibc-many-builds with
> {checkout,host-libraries,compilers} after we update the branch?
> 
> We would need to rebuild the toolchain anyway for rv32 anyway?

Yes, at least 'checkout' to get the most recent glibc and 'compilers'
to build a proper toolchain with the expect baseline ABI.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20201007/240d8eec/attachment.sig>


More information about the Libc-alpha mailing list