[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180614005442.GK1392@brightrain.aerifal.cx>
Date: Wed, 13 Jun 2018 20:54:42 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: broken __kernel_mode_t affecting some big endian archs
It's been semi-known for a long time (I say semi-, because nobody's
had the setup to test most of them well, or at least nobody I'm
communicating with regularly) that some archs are failing libc-test
sysvipc tests. I think I've tracked down the root cause.
Linux defined __kernel_mode_t as short on some old archs, and used it
in place of mode_t in the ipc_perm structure. The field is padded out
to 32 bits, so on little endian archs it's no problem for us to just
(as we do) ignore the incorrect type and declare the structure with
mode_t, as POSIX requires. However on big-endian archs, the padding is
on the wrong side and this trick doesn't work.
On MIPS we fixed a similar issue in struct stat, where dev_t was
incorrectly padded, with a fixup in syscall_arch.h. However this time
a large number of archs are affected, and patching them all up
individually seems nasty.
My leaning is to have syscall_arch.h expose a macro indicating the
bug, and have msgctl, semctl, and shmctl each do the fixup if it's
set.
FWIW the affected archs seem to be (only in big endian variants):
- ARM
- M68k (in-progress port)
- Microblaze
- SH
- Sparc (future port)
Thoughts?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
