Re: [PATCH] linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures

On 8/3/26 23:42, Andreas Schwab wrote:
> On Aug 03 2026, Helge Deller wrote:
>=20
>> * Andreas Schwab <[email protected]>:
>>> On Aug 01 2026, Helge Deller wrote:
>>>
>>>> m68k could be a problem.
>>>> The other big-arches seem to be handled correctly by the kernel:
>>>> arch/sparc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>>>> arch/parisc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>>>> arch/xtensa/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>>>> arch/x86/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>>>> arch/powerpc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>>>> arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>>>> arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>>>> arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>>>
>>> glibc commit 9f9feb6d5d says:
>>>
>>>      * Some older 32-bit big-endian architectures have padding before
>>>        rather than after time fields, although the preferred generic
>>>        approach is padding after the time fields independent of endian=
ness.
>>>
>>> and m68k uses the "preferred" approach.
>>
>> Thanks for the info, Andreas!
>> The msgctl01 LTP testcase does work correctly on a physical m68k
>> machine for me, so glibc/kernel seems ok, esp. regarding msqid64_ds.
>=20
> Which glibc version did you test?=20

(m68k-chroot)root@p100:/# cat /etc/debian_version
forky/sid

(m68k-chroot)root@p100:/# dpkg -l | grep libc6
ii  libc6:m68k                    2.42-17                   m68k         G=
NU C Library: Shared libraries
ii  libc6-dev:m68k                2.42-17                   m68k         G=
NU C Library: Development Libraries and Header Files

> Did you test _TIME_BITS=3D64?

Yes, because on Debian this is the default for all 32-bit architectures no=
w
(with exception of 32-bit x86).

>  This "preferred" approach does not really make any sense at all.

Right. IMHO this "preferred" (aka padding behind 32-bit time value even on=
 big-endian)
doesn't make any sense for big-endian. The lower 32-bit value then ends up=
 in the upper
32-bits of a 64-bit time_t value and thus you have problems when mixing 32=
- and 64-bit
time_t applications.
I think m68k needs to follow the other 32-bit big-endian arches I mentione=
d above
and provide an own uapi/asm/msgbuf.h:struct msqid64_ds file/struct.
And this stupid "preferred" sentence in the kernel should be dropped.

Helge