On 13/10/2020 10:58, 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}).
>>
> 
> I'm not sure if this is related, but on my ARMv7 (32 bit) sandbox there
> is an issue with fstat accesses to files.
> 
> When I try to run a program build against newest glibc (installed in
> /opt/lib) I do see issues with {f}stat on other libraries (e.g.
> /opt/lib/librt.so). To be more specific I do experience the EOVERFLOW
> error:
> 
> error while loading shared libraries: librt.so.1: cannot stat shared
> object: Error 75
> 
> The "base" glibc is 2.28 (installed in /lib). The glibc under test is
> the newest master installed in /opt/lib.
> 
> I'm now investigating this issue.

I am not sure what it might be based on these information, could you
provide a strace so we can pinpoint what might the issue?  

The arm-linux-gnueabihf testing I did was on a aarch64 kernel (4.12.13).
Besides the make check without regression, I could run system binaries 
with ./testrun.sh.

I will check on a different kernel/system with a 32-bit kernel.