On Sun, Apr 22, 2018 at 2:38 PM, H.J. Lu hjl.tools@gmail.com wrote:
On Fri, Apr 20, 2018 at 7:38 AM, Arnd Bergmann arnd@arndb.de wrote:
On Fri, Apr 20, 2018 at 3:53 PM, Jeffrey Walton noloader@gmail.com wrote:
Glibc has correct header files for system calls. I have a very old program to check if Linux kernel header files are correct for user space:
https://github.com/hjl-tools/linux-header
It needs update to check uapi.
Simply running 'make' on a regular distro shows this output:
--- kernel.x32.out 2018-04-22 22:10:16.053432423 +0200 +++ glibc.x32.out 2018-04-22 22:10:16.073432838 +0200 @@ -10,9 +10,9 @@ size of daddr_t: 4 size of __ipc_pid_t: 4 size of struct ipc_perm: 48 size of mqd_t: 4 -size of struct msqid_ds: 144 +size of struct msqid_ds: 120 size of struct semid_ds: 104 -size of struct shmid_ds: 136 +size of struct shmid_ds: 112 size of struct shminfo: 72 size of struct timeval: 16 size of struct timespec: 16 @@ -22,8 +22,8 @@ size of struct mq_attr: 64 size of struct rlimit: 16 size of struct rusage: 144 size of struct stat: 144 -size of struct statfs: 64 -size of struct statfs64: 88 +size of struct statfs: 120 +size of struct statfs64: 120 size of struct timex: 208 size of struct msginfo: 32 size of struct msgbuf: 16
This seems plausible, the statfs structure clearly has the same problem as msqid_ds/shmid_ds based on its usage of '__statfs_word' which is now defined as '__u32' rather than '__kernel_long_t'.
It should be trivial to override __statfs_word from arch/x86/include/uapi/asm/statfs.h
I've checked the other uses of __BITS_PER_LONG in the uapi headers now, and all the others are either not relevant for x32 (either definition is fine) or it has to be __BITS_PER_LONG=32.
Arnd