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

[Andreas Schwab <schwab@linux-m68k.org>]

On Aug 03 2026, Helge Deller wrote:

> * Andreas Schwab <schwab@linux-m68k.org>:
>> 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 endianness.
>> 
>> 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.

Which glibc version did you test?  Did you test _TIME_BITS=64?  This
"preferred" approach does not really make any sense at all.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."