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.