Re: [musl] no 32bit timestamp compatible stat/lstat/fstat?

[Rich Felker <dalias@libc.org>]

On Tue, Nov 30, 2021 at 12:15:59AM +0100, Norbert van Bolhuis wrote:
> Hi Rich,
> 
> Thanks for your answer!
> 
> Ah, it's about 32-bit off_t compatibility, but then why
> does musl-1.1.24 (and the corresponding libc6-compat package on
> Alpine 3.12) provide this (ancient) __fxstat function?

The symbol there in 1.1.x didn't behave as needed to make 32-bit-off_t
glibc code work. It just happened to be there as an alternate name for
the 64-bit-off_t function __fxstat64 as a consequence of 32-bit archs
not being special-cased.

> So this can never work properly and the reason why it worked with
> Alpine 3.12 (musl-1.1.24) is that the 3rd-party binary never really
> used __fxstat (because there is no way the 64-bit structure is
> compatible with the 32-bit one), right?

Right. Well, it might have 'worked' if it didn't actually inspect the
fields of the structure, but since the 64-bit structure is larger than
the object the caller provided, it was overflowing a buffer and
probably clobbering other data.

> Glibc does provide the ancient 32-bit variant, see:
> nm -D --defined-only /lib/arm-linux-gnueabihf/libc.so.6 | grep __fxstat
> 00093e68 T __fxstat
> 00093fdc T __fxstat64
> 000942a4 T __fxstatat
> 00094320 T __fxstatat64
> I would expect musl libc6-compat package to provide it, why it doesn't?

There's no way to support the 32-bit-off_t ABI with just a library,
because the symbol names clash. It would require musl's dynamic linker
to be specifically aware of foreign glibc libraries and remap their
symbol references. This would be something of a cooperative project
between musl and the folks working on gcompat to come up with a
contract between them for making it all work -- something we've talked
about as a vague future goal.

Rich