[PATCH 0/2] linux: Keep time64 stat layout independent of feature macros

[Adhemerval Zanella Netto]

On 05/08/26 23:02, Matthias Goergens wrote:
> Thanks for squashing this together with the generic-header fix.
> 
> I ran an independent cross-ABI compile-time layout check against your
> squashed commit (ecf95727a787) versus pre-fix master (d6031665).  The
> probe includes the actual bits/struct_stat.h and
> bits/struct_stat_time64_helper.h from each commit and records sizeof and
> 16 member offsets of struct stat for _TIME_BITS=64
> _FILE_OFFSET_BITS=64 in five feature modes: default (_GNU_SOURCE),
> POSIX.1-1996, POSIX.1-2001, POSIX.1-2008, and X/Open 600.  Targets are
> compiled with clang --target; arc and or1k are modeled on the
> layout-equivalent i386 (LE, alignof(long long)==4) and powerpc (BE,
> alignof(long long)==8) backends since clang has no ARC/OpenRISC backend.
> The i386 model reproduces the sizes and offsets measured against real
> glibc 2.44 headers.

Thanks for checking this out. You can bootstrap a cross-compiling gcc for
any supported target using the script/build-many-glibcs.py. It helps such
tests a lot.

> 
> Result: the layout is feature-mode-invariant on every target after your
> change.
> 
>   target    pre-fix strict modes vs default          post-fix
>   i386      size 116 vs 108, nsec order flipped      all modes identical (108)
>   arm       size 120 vs 112                          all modes identical (112)
>   powerpc   size 120 vs 112                          all modes identical (112)
>   mips o32  size 120 vs 112                          all modes identical (112)
>   mipsel    size 120 vs 112, nsec order flipped      all modes identical (112)
>   riscv32   already invariant                        all modes identical (128)
>   arc       size 116 vs 128, timestamps 12 apart     all modes identical (128)
>   or1k      nsec on wrong side of padding            all modes identical (128)
> 
> The generic-header fix lands exactly as your commit message describes:
> arc is now byte-identical to riscv32 on all measured values, and or1k
> matches riscv32 except the nanosecond fields at +12, the correct
> big-endian side.  The default-mode layout is unchanged on every target,
> so the fix only moves the strict modes onto the existing ABI.  riscv32
> was already invariant before the fix, consistent with your analysis.
> 
> Caveats: this is a compile-time layout model, not configured cross
> builds, and the arc/or1k rows rest on the backend equivalence noted
> above.  microblazeel is not covered (no clang backend); as a
> helper-family port without its own endian include it follows the mipsel
> pattern.
> 
> Matthias