* [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem @ 2019-07-03 0:52 ` Alistair Francis 0 siblings, 0 replies; 16+ messages in thread From: Alistair Francis @ 2019-07-03 0:52 UTC (permalink / raw) To: linux-riscv, arnd; +Cc: linux-kernel, alistair23, Alistair Francis Resending the the correct linux-riscv address. In the RISC-V 32-bit glibc port [1] the siginfo_t struct in the kernel doesn't line up with the struct in glibc. In glibc world the _sifields union is 8 byte alligned (although I can't figure out why) while in the kernel wordl the _sifields union is 4 bytes alligned. This results in information being lost in the waitid syscall. This doesn't seem to be a great fix, but it is somewhat similar to what x32 does (which has 64-bit time_t like RV32) and I can't figure out why the two allignments are different. 1: https://github.com/alistair23/glibc/commits/alistair/rv32.next Alistair Francis (2): uapi/asm-generic: Allow defining a custom __SIGINFO struct riscv/include/uapi: Define a custom __SIGINFO struct for RV32 arch/riscv/include/uapi/asm/siginfo.h | 32 +++++++++++++++++++++++++++ include/uapi/asm-generic/siginfo.h | 32 ++++++++++++++------------- 2 files changed, 49 insertions(+), 15 deletions(-) create mode 100644 arch/riscv/include/uapi/asm/siginfo.h -- 2.22.0 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem @ 2019-07-03 0:52 ` Alistair Francis 0 siblings, 0 replies; 16+ messages in thread From: Alistair Francis @ 2019-07-03 0:52 UTC (permalink / raw) To: linux-riscv, arnd; +Cc: alistair23, Alistair Francis, linux-kernel Resending the the correct linux-riscv address. In the RISC-V 32-bit glibc port [1] the siginfo_t struct in the kernel doesn't line up with the struct in glibc. In glibc world the _sifields union is 8 byte alligned (although I can't figure out why) while in the kernel wordl the _sifields union is 4 bytes alligned. This results in information being lost in the waitid syscall. This doesn't seem to be a great fix, but it is somewhat similar to what x32 does (which has 64-bit time_t like RV32) and I can't figure out why the two allignments are different. 1: https://github.com/alistair23/glibc/commits/alistair/rv32.next Alistair Francis (2): uapi/asm-generic: Allow defining a custom __SIGINFO struct riscv/include/uapi: Define a custom __SIGINFO struct for RV32 arch/riscv/include/uapi/asm/siginfo.h | 32 +++++++++++++++++++++++++++ include/uapi/asm-generic/siginfo.h | 32 ++++++++++++++------------- 2 files changed, 49 insertions(+), 15 deletions(-) create mode 100644 arch/riscv/include/uapi/asm/siginfo.h -- 2.22.0 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH RESEND 1/2] uapi/asm-generic: Allow defining a custom __SIGINFO struct 2019-07-03 0:52 ` Alistair Francis @ 2019-07-03 0:52 ` Alistair Francis -1 siblings, 0 replies; 16+ messages in thread From: Alistair Francis @ 2019-07-03 0:52 UTC (permalink / raw) To: linux-riscv, arnd; +Cc: linux-kernel, alistair23, Alistair Francis Allow defining a custom __SIGINFO struct. This allows architectures to apply their own padding and allignment requirements to the struct. This is similar to the __ARCH_SI_ATTRIBUTES #define that already exists, but applies to the __SIGINFO struct instead of the siginfo_t struct. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> --- include/uapi/asm-generic/siginfo.h | 32 ++++++++++++++++-------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h index cb3d6c267181..09b0a1abac14 100644 --- a/include/uapi/asm-generic/siginfo.h +++ b/include/uapi/asm-generic/siginfo.h @@ -108,23 +108,25 @@ union __sifields { } _sigsys; }; -#ifndef __ARCH_HAS_SWAPPED_SIGINFO -#define __SIGINFO \ -struct { \ - int si_signo; \ - int si_errno; \ - int si_code; \ - union __sifields _sifields; \ +#ifndef __SIGINFO +# ifndef __ARCH_HAS_SWAPPED_SIGINFO +# define __SIGINFO \ +struct { \ + int si_signo; \ + int si_errno; \ + int si_code; \ + union __sifields _sifields __ARCH_SI_ATTRIBUTES; \ } -#else -#define __SIGINFO \ -struct { \ - int si_signo; \ - int si_code; \ - int si_errno; \ - union __sifields _sifields; \ +# else +# define __SIGINFO \ +struct { \ + int si_signo; \ + int si_code; \ + int si_errno; \ + union __sifields _sifields __ARCH_SI_ATTRIBUTES; \ } -#endif /* __ARCH_HAS_SWAPPED_SIGINFO */ +# endif /* __ARCH_HAS_SWAPPED_SIGINFO */ +#endif /* __SIGINFO */ typedef struct siginfo { union { -- 2.22.0 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH RESEND 1/2] uapi/asm-generic: Allow defining a custom __SIGINFO struct @ 2019-07-03 0:52 ` Alistair Francis 0 siblings, 0 replies; 16+ messages in thread From: Alistair Francis @ 2019-07-03 0:52 UTC (permalink / raw) To: linux-riscv, arnd; +Cc: alistair23, Alistair Francis, linux-kernel Allow defining a custom __SIGINFO struct. This allows architectures to apply their own padding and allignment requirements to the struct. This is similar to the __ARCH_SI_ATTRIBUTES #define that already exists, but applies to the __SIGINFO struct instead of the siginfo_t struct. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> --- include/uapi/asm-generic/siginfo.h | 32 ++++++++++++++++-------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h index cb3d6c267181..09b0a1abac14 100644 --- a/include/uapi/asm-generic/siginfo.h +++ b/include/uapi/asm-generic/siginfo.h @@ -108,23 +108,25 @@ union __sifields { } _sigsys; }; -#ifndef __ARCH_HAS_SWAPPED_SIGINFO -#define __SIGINFO \ -struct { \ - int si_signo; \ - int si_errno; \ - int si_code; \ - union __sifields _sifields; \ +#ifndef __SIGINFO +# ifndef __ARCH_HAS_SWAPPED_SIGINFO +# define __SIGINFO \ +struct { \ + int si_signo; \ + int si_errno; \ + int si_code; \ + union __sifields _sifields __ARCH_SI_ATTRIBUTES; \ } -#else -#define __SIGINFO \ -struct { \ - int si_signo; \ - int si_code; \ - int si_errno; \ - union __sifields _sifields; \ +# else +# define __SIGINFO \ +struct { \ + int si_signo; \ + int si_code; \ + int si_errno; \ + union __sifields _sifields __ARCH_SI_ATTRIBUTES; \ } -#endif /* __ARCH_HAS_SWAPPED_SIGINFO */ +# endif /* __ARCH_HAS_SWAPPED_SIGINFO */ +#endif /* __SIGINFO */ typedef struct siginfo { union { -- 2.22.0 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH RESEND 2/2] riscv/include/uapi: Define a custom __SIGINFO struct for RV32 2019-07-03 0:52 ` Alistair Francis @ 2019-07-03 0:52 ` Alistair Francis -1 siblings, 0 replies; 16+ messages in thread From: Alistair Francis @ 2019-07-03 0:52 UTC (permalink / raw) To: linux-riscv, arnd; +Cc: linux-kernel, alistair23, Alistair Francis The glibc implementation of siginfo_t results in an allignment of 8 bytes for the union _sifields on RV32. The kernel has an allignment of 4 bytes for the _sifields union. This results in information being lost when glibc parses the siginfo_t struct. To fix the issue add a pad variable to the struct to avoid allignment mismatches. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> --- arch/riscv/include/uapi/asm/siginfo.h | 32 +++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 arch/riscv/include/uapi/asm/siginfo.h diff --git a/arch/riscv/include/uapi/asm/siginfo.h b/arch/riscv/include/uapi/asm/siginfo.h new file mode 100644 index 000000000000..0854ad97bf44 --- /dev/null +++ b/arch/riscv/include/uapi/asm/siginfo.h @@ -0,0 +1,32 @@ +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ +#ifndef _ASM_RISCV_SIGINFO_H +#define _ASM_RISCV_SIGINFO_H + +/* Add a pad element for RISC-V 32-bit. We need this as the + * _sifields union is 8 byte allgined in usperace. + */ +#if __riscv_xlen == 32 +#ifndef __ARCH_HAS_SWAPPED_SIGINFO +#define __SIGINFO \ +struct { \ + int si_signo; \ + int si_errno; \ + int si_code; \ + int pad; \ + union __sifields _sifields; \ +} +#else +#define __SIGINFO \ +struct { \ + int si_signo; \ + int si_code; \ + int si_errno; \ + int pad; \ + union __sifields _sifields; \ +} +#endif /* __ARCH_HAS_SWAPPED_SIGINFO */ +#endif + +#include <asm-generic/siginfo.h> + +#endif /* _ASM_RISCV_SIGINFO_H */ -- 2.22.0 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH RESEND 2/2] riscv/include/uapi: Define a custom __SIGINFO struct for RV32 @ 2019-07-03 0:52 ` Alistair Francis 0 siblings, 0 replies; 16+ messages in thread From: Alistair Francis @ 2019-07-03 0:52 UTC (permalink / raw) To: linux-riscv, arnd; +Cc: alistair23, Alistair Francis, linux-kernel The glibc implementation of siginfo_t results in an allignment of 8 bytes for the union _sifields on RV32. The kernel has an allignment of 4 bytes for the _sifields union. This results in information being lost when glibc parses the siginfo_t struct. To fix the issue add a pad variable to the struct to avoid allignment mismatches. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> --- arch/riscv/include/uapi/asm/siginfo.h | 32 +++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 arch/riscv/include/uapi/asm/siginfo.h diff --git a/arch/riscv/include/uapi/asm/siginfo.h b/arch/riscv/include/uapi/asm/siginfo.h new file mode 100644 index 000000000000..0854ad97bf44 --- /dev/null +++ b/arch/riscv/include/uapi/asm/siginfo.h @@ -0,0 +1,32 @@ +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ +#ifndef _ASM_RISCV_SIGINFO_H +#define _ASM_RISCV_SIGINFO_H + +/* Add a pad element for RISC-V 32-bit. We need this as the + * _sifields union is 8 byte allgined in usperace. + */ +#if __riscv_xlen == 32 +#ifndef __ARCH_HAS_SWAPPED_SIGINFO +#define __SIGINFO \ +struct { \ + int si_signo; \ + int si_errno; \ + int si_code; \ + int pad; \ + union __sifields _sifields; \ +} +#else +#define __SIGINFO \ +struct { \ + int si_signo; \ + int si_code; \ + int si_errno; \ + int pad; \ + union __sifields _sifields; \ +} +#endif /* __ARCH_HAS_SWAPPED_SIGINFO */ +#endif + +#include <asm-generic/siginfo.h> + +#endif /* _ASM_RISCV_SIGINFO_H */ -- 2.22.0 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem 2019-07-03 0:52 ` Alistair Francis @ 2019-07-03 7:08 ` Andreas Schwab -1 siblings, 0 replies; 16+ messages in thread From: Andreas Schwab @ 2019-07-03 7:08 UTC (permalink / raw) To: Alistair Francis; +Cc: linux-riscv, arnd, linux-kernel, alistair23 On Jul 02 2019, Alistair Francis <alistair.francis@wdc.com> wrote: > In the RISC-V 32-bit glibc port [1] the siginfo_t struct in the kernel > doesn't line up with the struct in glibc. In glibc world the _sifields > union is 8 byte alligned (although I can't figure out why) Try ptype/o in gdb. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem @ 2019-07-03 7:08 ` Andreas Schwab 0 siblings, 0 replies; 16+ messages in thread From: Andreas Schwab @ 2019-07-03 7:08 UTC (permalink / raw) To: Alistair Francis; +Cc: alistair23, linux-riscv, linux-kernel, arnd On Jul 02 2019, Alistair Francis <alistair.francis@wdc.com> wrote: > In the RISC-V 32-bit glibc port [1] the siginfo_t struct in the kernel > doesn't line up with the struct in glibc. In glibc world the _sifields > union is 8 byte alligned (although I can't figure out why) Try ptype/o in gdb. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem 2019-07-03 7:08 ` Andreas Schwab @ 2019-07-03 18:40 ` Alistair Francis -1 siblings, 0 replies; 16+ messages in thread From: Alistair Francis @ 2019-07-03 18:40 UTC (permalink / raw) To: Andreas Schwab; +Cc: Alistair Francis, linux-riscv, Arnd Bergmann, linux-kernel On Wed, Jul 3, 2019 at 12:08 AM Andreas Schwab <schwab@suse.de> wrote: > > On Jul 02 2019, Alistair Francis <alistair.francis@wdc.com> wrote: > > > In the RISC-V 32-bit glibc port [1] the siginfo_t struct in the kernel > > doesn't line up with the struct in glibc. In glibc world the _sifields > > union is 8 byte alligned (although I can't figure out why) > > Try ptype/o in gdb. That's a useful tip, I'll be sure to use that next time. Alistair > > Andreas. > > -- > Andreas Schwab, SUSE Labs, schwab@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different." ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem @ 2019-07-03 18:40 ` Alistair Francis 0 siblings, 0 replies; 16+ messages in thread From: Alistair Francis @ 2019-07-03 18:40 UTC (permalink / raw) To: Andreas Schwab; +Cc: linux-riscv, Alistair Francis, linux-kernel, Arnd Bergmann On Wed, Jul 3, 2019 at 12:08 AM Andreas Schwab <schwab@suse.de> wrote: > > On Jul 02 2019, Alistair Francis <alistair.francis@wdc.com> wrote: > > > In the RISC-V 32-bit glibc port [1] the siginfo_t struct in the kernel > > doesn't line up with the struct in glibc. In glibc world the _sifields > > union is 8 byte alligned (although I can't figure out why) > > Try ptype/o in gdb. That's a useful tip, I'll be sure to use that next time. Alistair > > Andreas. > > -- > Andreas Schwab, SUSE Labs, schwab@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different." _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem 2019-07-03 18:40 ` Alistair Francis @ 2019-07-04 7:20 ` Andreas Schwab -1 siblings, 0 replies; 16+ messages in thread From: Andreas Schwab @ 2019-07-04 7:20 UTC (permalink / raw) To: Alistair Francis Cc: Alistair Francis, linux-riscv, Arnd Bergmann, linux-kernel On Jul 03 2019, Alistair Francis <alistair23@gmail.com> wrote: > On Wed, Jul 3, 2019 at 12:08 AM Andreas Schwab <schwab@suse.de> wrote: >> >> On Jul 02 2019, Alistair Francis <alistair.francis@wdc.com> wrote: >> >> > In the RISC-V 32-bit glibc port [1] the siginfo_t struct in the kernel >> > doesn't line up with the struct in glibc. In glibc world the _sifields >> > union is 8 byte alligned (although I can't figure out why) >> >> Try ptype/o in gdb. > > That's a useful tip, I'll be sure to use that next time. It was a serious note. If the structs don't line up then there is a mismatch in types that cannot be solved by adding spurious padding. You need to fix the types instead. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem @ 2019-07-04 7:20 ` Andreas Schwab 0 siblings, 0 replies; 16+ messages in thread From: Andreas Schwab @ 2019-07-04 7:20 UTC (permalink / raw) To: Alistair Francis Cc: linux-riscv, Alistair Francis, linux-kernel, Arnd Bergmann On Jul 03 2019, Alistair Francis <alistair23@gmail.com> wrote: > On Wed, Jul 3, 2019 at 12:08 AM Andreas Schwab <schwab@suse.de> wrote: >> >> On Jul 02 2019, Alistair Francis <alistair.francis@wdc.com> wrote: >> >> > In the RISC-V 32-bit glibc port [1] the siginfo_t struct in the kernel >> > doesn't line up with the struct in glibc. In glibc world the _sifields >> > union is 8 byte alligned (although I can't figure out why) >> >> Try ptype/o in gdb. > > That's a useful tip, I'll be sure to use that next time. It was a serious note. If the structs don't line up then there is a mismatch in types that cannot be solved by adding spurious padding. You need to fix the types instead. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem 2019-07-04 7:20 ` Andreas Schwab @ 2019-07-04 9:19 ` Arnd Bergmann -1 siblings, 0 replies; 16+ messages in thread From: Arnd Bergmann @ 2019-07-04 9:19 UTC (permalink / raw) To: Andreas Schwab Cc: Alistair Francis, Alistair Francis, linux-riscv, Linux Kernel Mailing List On Thu, Jul 4, 2019 at 9:20 AM Andreas Schwab <schwab@suse.de> wrote: > > On Jul 03 2019, Alistair Francis <alistair23@gmail.com> wrote: > > > On Wed, Jul 3, 2019 at 12:08 AM Andreas Schwab <schwab@suse.de> wrote: > >> > >> On Jul 02 2019, Alistair Francis <alistair.francis@wdc.com> wrote: > >> > >> > In the RISC-V 32-bit glibc port [1] the siginfo_t struct in the kernel > >> > doesn't line up with the struct in glibc. In glibc world the _sifields > >> > union is 8 byte alligned (although I can't figure out why) > >> > >> Try ptype/o in gdb. > > > > That's a useful tip, I'll be sure to use that next time. > > It was a serious note. If the structs don't line up then there is a > mismatch in types that cannot be solved by adding spurious padding. You > need to fix the types instead. Would it be an option to align all the basic typedefs (off_t, time_t, clock_t, ...) between glibc and kernel then, and just use the existing sysdeps/unix/sysv/linux/generic/bits/typesizes.h after all to avoid surprises like this? As of v2 the functional difference is -#define __INO_T_TYPE __ULONGWORD_TYPE +#define __INO_T_TYPE __UQUAD_TYPE #define __INO64_T_TYPE __UQUAD_TYPE #define __MODE_T_TYPE __U32_TYPE -#define __NLINK_T_TYPE __U32_TYPE -#define __OFF_T_TYPE __SLONGWORD_TYPE +#define __NLINK_T_TYPE __UQUAD_TYPE +#define __OFF_T_TYPE __SQUAD_TYPE #define __OFF64_T_TYPE __SQUAD_TYPE -#define __RLIM_T_TYPE __ULONGWORD_TYPE +#define __RLIM_T_TYPE __UQUAD_TYPE #define __RLIM64_T_TYPE __UQUAD_TYPE -#define __BLKCNT_T_TYPE __SLONGWORD_TYPE +#define __BLKCNT_T_TYPE __SQUAD_TYPE #define __BLKCNT64_T_TYPE __SQUAD_TYPE -#define __FSBLKCNT_T_TYPE __ULONGWORD_TYPE +#define __FSBLKCNT_T_TYPE __UQUAD_TYPE #define __FSBLKCNT64_T_TYPE __UQUAD_TYPE -#define __FSFILCNT_T_TYPE __ULONGWORD_TYPE +#define __FSFILCNT_T_TYPE __UQUAD_TYPE #define __FSFILCNT64_T_TYPE __UQUAD_TYPE -#define __FSWORD_T_TYPE __SWORD_TYPE +#define __FSWORD_T_TYPE __SQUAD_TYPE -#define __CLOCK_T_TYPE __SLONGWORD_TYPE -#define __TIME_T_TYPE __SLONGWORD_TYPE +#define __CLOCK_T_TYPE __SQUAD_TYPE +#define __TIME_T_TYPE __SQUAD_TYPE #define __USECONDS_T_TYPE __U32_TYPE -#define __SUSECONDS_T_TYPE __SLONGWORD_TYPE +#define __SUSECONDS_T_TYPE __SQUAD_TYPE -#define __BLKSIZE_T_TYPE __S32_TYPE +#define __BLKSIZE_T_TYPE __SQUAD_TYPE #define __FSID_T_TYPE struct { int __val[2]; } #define __SSIZE_T_TYPE __SWORD_TYPE -#define __SYSCALL_SLONG_TYPE __SLONGWORD_TYPE -#define __SYSCALL_ULONG_TYPE __ULONGWORD_TYPE -#define __CPU_MASK_TYPE __ULONGWORD_TYPE +#define __SYSCALL_SLONG_TYPE __SQUAD_TYPE +#define __SYSCALL_ULONG_TYPE __UQUAD_TYPE +#define __CPU_MASK_TYPE __UQUAD_TYPE -#ifdef __LP64__ # define __RLIM_T_MATCHES_RLIM64_T 1 -#else -# define __RLIM_T_MATCHES_RLIM64_T 0 -#endif +#define __ASSUME_TIME64_SYSCALLS 1 +#define __ASSUME_RLIM64_SYSCALLS 1 Since the sysdeps/unix/sysv/linux/generic/bits/typesizes.h definitions generally match the kernel, anything diverging from that has the potential of breaking it, so the difference should probably be kept to the absolute minimum. I think these ones are wrong and will cause bugs similar to the clock_t issue if they are used with kernel interfaces: __NLINK_T_TYPE, __FSWORD_T_TYPE, __CLOCK_T_TYPE, __BLKSIZE_T_TYPE, __SYSCALL_ULONG_TYPE, __SYSCALL_SLONG_TYPE, __CPU_MASK_TYPE These are fine as long as they are only used in user space and to wrap kernel syscalls, but I think most of them can end up being passed to the kernel, so it seems safer not to have rv32 diverge without a good reason. The remaining ones (__INO_T_TYPE, __OFF_T_TYPE, __BLKCNT_T_TYPE, __FSBLKCNT_T_TYPE, __FSFILCNT_T_TYPE, __TIME_T_TYPE) all follow the pattern where the kernel has an old 32-bit type and a new 64-bit type, but the kernel tries not to expose the 32-bit interfaces to user space on new architectures and only provide the 64-bit replacements, but there are a couple of interfaces that never got replaced, typically in driver and file system ioctls. Since glibc already has code to deal with the 64-bit types and that is well tested, it would seem safer to me to just #undef the old types completely rather than defining them to 64-bit, which would make them incompatible with the kernel's types. Arnd ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem @ 2019-07-04 9:19 ` Arnd Bergmann 0 siblings, 0 replies; 16+ messages in thread From: Arnd Bergmann @ 2019-07-04 9:19 UTC (permalink / raw) To: Andreas Schwab Cc: Alistair Francis, linux-riscv, Alistair Francis, Linux Kernel Mailing List On Thu, Jul 4, 2019 at 9:20 AM Andreas Schwab <schwab@suse.de> wrote: > > On Jul 03 2019, Alistair Francis <alistair23@gmail.com> wrote: > > > On Wed, Jul 3, 2019 at 12:08 AM Andreas Schwab <schwab@suse.de> wrote: > >> > >> On Jul 02 2019, Alistair Francis <alistair.francis@wdc.com> wrote: > >> > >> > In the RISC-V 32-bit glibc port [1] the siginfo_t struct in the kernel > >> > doesn't line up with the struct in glibc. In glibc world the _sifields > >> > union is 8 byte alligned (although I can't figure out why) > >> > >> Try ptype/o in gdb. > > > > That's a useful tip, I'll be sure to use that next time. > > It was a serious note. If the structs don't line up then there is a > mismatch in types that cannot be solved by adding spurious padding. You > need to fix the types instead. Would it be an option to align all the basic typedefs (off_t, time_t, clock_t, ...) between glibc and kernel then, and just use the existing sysdeps/unix/sysv/linux/generic/bits/typesizes.h after all to avoid surprises like this? As of v2 the functional difference is -#define __INO_T_TYPE __ULONGWORD_TYPE +#define __INO_T_TYPE __UQUAD_TYPE #define __INO64_T_TYPE __UQUAD_TYPE #define __MODE_T_TYPE __U32_TYPE -#define __NLINK_T_TYPE __U32_TYPE -#define __OFF_T_TYPE __SLONGWORD_TYPE +#define __NLINK_T_TYPE __UQUAD_TYPE +#define __OFF_T_TYPE __SQUAD_TYPE #define __OFF64_T_TYPE __SQUAD_TYPE -#define __RLIM_T_TYPE __ULONGWORD_TYPE +#define __RLIM_T_TYPE __UQUAD_TYPE #define __RLIM64_T_TYPE __UQUAD_TYPE -#define __BLKCNT_T_TYPE __SLONGWORD_TYPE +#define __BLKCNT_T_TYPE __SQUAD_TYPE #define __BLKCNT64_T_TYPE __SQUAD_TYPE -#define __FSBLKCNT_T_TYPE __ULONGWORD_TYPE +#define __FSBLKCNT_T_TYPE __UQUAD_TYPE #define __FSBLKCNT64_T_TYPE __UQUAD_TYPE -#define __FSFILCNT_T_TYPE __ULONGWORD_TYPE +#define __FSFILCNT_T_TYPE __UQUAD_TYPE #define __FSFILCNT64_T_TYPE __UQUAD_TYPE -#define __FSWORD_T_TYPE __SWORD_TYPE +#define __FSWORD_T_TYPE __SQUAD_TYPE -#define __CLOCK_T_TYPE __SLONGWORD_TYPE -#define __TIME_T_TYPE __SLONGWORD_TYPE +#define __CLOCK_T_TYPE __SQUAD_TYPE +#define __TIME_T_TYPE __SQUAD_TYPE #define __USECONDS_T_TYPE __U32_TYPE -#define __SUSECONDS_T_TYPE __SLONGWORD_TYPE +#define __SUSECONDS_T_TYPE __SQUAD_TYPE -#define __BLKSIZE_T_TYPE __S32_TYPE +#define __BLKSIZE_T_TYPE __SQUAD_TYPE #define __FSID_T_TYPE struct { int __val[2]; } #define __SSIZE_T_TYPE __SWORD_TYPE -#define __SYSCALL_SLONG_TYPE __SLONGWORD_TYPE -#define __SYSCALL_ULONG_TYPE __ULONGWORD_TYPE -#define __CPU_MASK_TYPE __ULONGWORD_TYPE +#define __SYSCALL_SLONG_TYPE __SQUAD_TYPE +#define __SYSCALL_ULONG_TYPE __UQUAD_TYPE +#define __CPU_MASK_TYPE __UQUAD_TYPE -#ifdef __LP64__ # define __RLIM_T_MATCHES_RLIM64_T 1 -#else -# define __RLIM_T_MATCHES_RLIM64_T 0 -#endif +#define __ASSUME_TIME64_SYSCALLS 1 +#define __ASSUME_RLIM64_SYSCALLS 1 Since the sysdeps/unix/sysv/linux/generic/bits/typesizes.h definitions generally match the kernel, anything diverging from that has the potential of breaking it, so the difference should probably be kept to the absolute minimum. I think these ones are wrong and will cause bugs similar to the clock_t issue if they are used with kernel interfaces: __NLINK_T_TYPE, __FSWORD_T_TYPE, __CLOCK_T_TYPE, __BLKSIZE_T_TYPE, __SYSCALL_ULONG_TYPE, __SYSCALL_SLONG_TYPE, __CPU_MASK_TYPE These are fine as long as they are only used in user space and to wrap kernel syscalls, but I think most of them can end up being passed to the kernel, so it seems safer not to have rv32 diverge without a good reason. The remaining ones (__INO_T_TYPE, __OFF_T_TYPE, __BLKCNT_T_TYPE, __FSBLKCNT_T_TYPE, __FSFILCNT_T_TYPE, __TIME_T_TYPE) all follow the pattern where the kernel has an old 32-bit type and a new 64-bit type, but the kernel tries not to expose the 32-bit interfaces to user space on new architectures and only provide the 64-bit replacements, but there are a couple of interfaces that never got replaced, typically in driver and file system ioctls. Since glibc already has code to deal with the 64-bit types and that is well tested, it would seem safer to me to just #undef the old types completely rather than defining them to 64-bit, which would make them incompatible with the kernel's types. Arnd _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem 2019-07-04 9:19 ` Arnd Bergmann @ 2019-07-17 0:02 ` Alistair Francis -1 siblings, 0 replies; 16+ messages in thread From: Alistair Francis @ 2019-07-17 0:02 UTC (permalink / raw) To: Arnd Bergmann Cc: Andreas Schwab, Alistair Francis, linux-riscv, Linux Kernel Mailing List On Thu, Jul 4, 2019 at 2:19 AM Arnd Bergmann <arnd@arndb.de> wrote: > > On Thu, Jul 4, 2019 at 9:20 AM Andreas Schwab <schwab@suse.de> wrote: > > > > On Jul 03 2019, Alistair Francis <alistair23@gmail.com> wrote: > > > > > On Wed, Jul 3, 2019 at 12:08 AM Andreas Schwab <schwab@suse.de> wrote: > > >> > > >> On Jul 02 2019, Alistair Francis <alistair.francis@wdc.com> wrote: > > >> > > >> > In the RISC-V 32-bit glibc port [1] the siginfo_t struct in the kernel > > >> > doesn't line up with the struct in glibc. In glibc world the _sifields > > >> > union is 8 byte alligned (although I can't figure out why) > > >> > > >> Try ptype/o in gdb. > > > > > > That's a useful tip, I'll be sure to use that next time. > > > > It was a serious note. If the structs don't line up then there is a > > mismatch in types that cannot be solved by adding spurious padding. You > > need to fix the types instead. > > Would it be an option to align all the basic typedefs (off_t, time_t, > clock_t, ...) > between glibc and kernel then, and just use the existing > sysdeps/unix/sysv/linux/generic/bits/typesizes.h after all to avoid > surprises like this? > > As of v2 the functional difference is > > -#define __INO_T_TYPE __ULONGWORD_TYPE > +#define __INO_T_TYPE __UQUAD_TYPE > #define __INO64_T_TYPE __UQUAD_TYPE > #define __MODE_T_TYPE __U32_TYPE > -#define __NLINK_T_TYPE __U32_TYPE > -#define __OFF_T_TYPE __SLONGWORD_TYPE > +#define __NLINK_T_TYPE __UQUAD_TYPE > +#define __OFF_T_TYPE __SQUAD_TYPE > #define __OFF64_T_TYPE __SQUAD_TYPE > -#define __RLIM_T_TYPE __ULONGWORD_TYPE > +#define __RLIM_T_TYPE __UQUAD_TYPE > #define __RLIM64_T_TYPE __UQUAD_TYPE > -#define __BLKCNT_T_TYPE __SLONGWORD_TYPE > +#define __BLKCNT_T_TYPE __SQUAD_TYPE > #define __BLKCNT64_T_TYPE __SQUAD_TYPE > -#define __FSBLKCNT_T_TYPE __ULONGWORD_TYPE > +#define __FSBLKCNT_T_TYPE __UQUAD_TYPE > #define __FSBLKCNT64_T_TYPE __UQUAD_TYPE > -#define __FSFILCNT_T_TYPE __ULONGWORD_TYPE > +#define __FSFILCNT_T_TYPE __UQUAD_TYPE > #define __FSFILCNT64_T_TYPE __UQUAD_TYPE > -#define __FSWORD_T_TYPE __SWORD_TYPE > +#define __FSWORD_T_TYPE __SQUAD_TYPE > -#define __CLOCK_T_TYPE __SLONGWORD_TYPE > -#define __TIME_T_TYPE __SLONGWORD_TYPE > +#define __CLOCK_T_TYPE __SQUAD_TYPE > +#define __TIME_T_TYPE __SQUAD_TYPE > #define __USECONDS_T_TYPE __U32_TYPE > -#define __SUSECONDS_T_TYPE __SLONGWORD_TYPE > +#define __SUSECONDS_T_TYPE __SQUAD_TYPE > -#define __BLKSIZE_T_TYPE __S32_TYPE > +#define __BLKSIZE_T_TYPE __SQUAD_TYPE > #define __FSID_T_TYPE struct { int __val[2]; } > #define __SSIZE_T_TYPE __SWORD_TYPE > -#define __SYSCALL_SLONG_TYPE __SLONGWORD_TYPE > -#define __SYSCALL_ULONG_TYPE __ULONGWORD_TYPE > -#define __CPU_MASK_TYPE __ULONGWORD_TYPE > +#define __SYSCALL_SLONG_TYPE __SQUAD_TYPE > +#define __SYSCALL_ULONG_TYPE __UQUAD_TYPE > +#define __CPU_MASK_TYPE __UQUAD_TYPE > > -#ifdef __LP64__ > # define __RLIM_T_MATCHES_RLIM64_T 1 > -#else > -# define __RLIM_T_MATCHES_RLIM64_T 0 > -#endif > > +#define __ASSUME_TIME64_SYSCALLS 1 > +#define __ASSUME_RLIM64_SYSCALLS 1 > > Since the sysdeps/unix/sysv/linux/generic/bits/typesizes.h definitions > generally match the kernel, anything diverging from that has the potential > of breaking it, so the difference should probably be kept to the absolute > minimum. > > I think these ones are wrong and will cause bugs similar to the clock_t > issue if they are used with kernel interfaces: > __NLINK_T_TYPE, __FSWORD_T_TYPE, __CLOCK_T_TYPE, > __BLKSIZE_T_TYPE, __SYSCALL_ULONG_TYPE, > __SYSCALL_SLONG_TYPE, __CPU_MASK_TYPE > > These are fine as long as they are only used in user space and to > wrap kernel syscalls, but I think most of them can end up being > passed to the kernel, so it seems safer not to have rv32 diverge > without a good reason. > > The remaining ones (__INO_T_TYPE, __OFF_T_TYPE, __BLKCNT_T_TYPE, > __FSBLKCNT_T_TYPE, __FSFILCNT_T_TYPE, __TIME_T_TYPE) all > follow the pattern where the kernel has an old 32-bit type and a new > 64-bit type, but the kernel tries not to expose the 32-bit interfaces > to user space on new architectures and only provide the 64-bit > replacements, but there are a couple of interfaces that never got > replaced, typically in driver and file system ioctls. > > Since glibc already has code to deal with the 64-bit types and that > is well tested, it would seem safer to me to just #undef the old > types completely rather than defining them to 64-bit, which would > make them incompatible with the kernel's types. #undef-ing these results in build failures unfortunately, it seems like they are required. I'm sending a v3 RFC to the glibc list right now. We can continue the discussion there. Alistair > > Arnd ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem @ 2019-07-17 0:02 ` Alistair Francis 0 siblings, 0 replies; 16+ messages in thread From: Alistair Francis @ 2019-07-17 0:02 UTC (permalink / raw) To: Arnd Bergmann Cc: Andreas Schwab, linux-riscv, Alistair Francis, Linux Kernel Mailing List On Thu, Jul 4, 2019 at 2:19 AM Arnd Bergmann <arnd@arndb.de> wrote: > > On Thu, Jul 4, 2019 at 9:20 AM Andreas Schwab <schwab@suse.de> wrote: > > > > On Jul 03 2019, Alistair Francis <alistair23@gmail.com> wrote: > > > > > On Wed, Jul 3, 2019 at 12:08 AM Andreas Schwab <schwab@suse.de> wrote: > > >> > > >> On Jul 02 2019, Alistair Francis <alistair.francis@wdc.com> wrote: > > >> > > >> > In the RISC-V 32-bit glibc port [1] the siginfo_t struct in the kernel > > >> > doesn't line up with the struct in glibc. In glibc world the _sifields > > >> > union is 8 byte alligned (although I can't figure out why) > > >> > > >> Try ptype/o in gdb. > > > > > > That's a useful tip, I'll be sure to use that next time. > > > > It was a serious note. If the structs don't line up then there is a > > mismatch in types that cannot be solved by adding spurious padding. You > > need to fix the types instead. > > Would it be an option to align all the basic typedefs (off_t, time_t, > clock_t, ...) > between glibc and kernel then, and just use the existing > sysdeps/unix/sysv/linux/generic/bits/typesizes.h after all to avoid > surprises like this? > > As of v2 the functional difference is > > -#define __INO_T_TYPE __ULONGWORD_TYPE > +#define __INO_T_TYPE __UQUAD_TYPE > #define __INO64_T_TYPE __UQUAD_TYPE > #define __MODE_T_TYPE __U32_TYPE > -#define __NLINK_T_TYPE __U32_TYPE > -#define __OFF_T_TYPE __SLONGWORD_TYPE > +#define __NLINK_T_TYPE __UQUAD_TYPE > +#define __OFF_T_TYPE __SQUAD_TYPE > #define __OFF64_T_TYPE __SQUAD_TYPE > -#define __RLIM_T_TYPE __ULONGWORD_TYPE > +#define __RLIM_T_TYPE __UQUAD_TYPE > #define __RLIM64_T_TYPE __UQUAD_TYPE > -#define __BLKCNT_T_TYPE __SLONGWORD_TYPE > +#define __BLKCNT_T_TYPE __SQUAD_TYPE > #define __BLKCNT64_T_TYPE __SQUAD_TYPE > -#define __FSBLKCNT_T_TYPE __ULONGWORD_TYPE > +#define __FSBLKCNT_T_TYPE __UQUAD_TYPE > #define __FSBLKCNT64_T_TYPE __UQUAD_TYPE > -#define __FSFILCNT_T_TYPE __ULONGWORD_TYPE > +#define __FSFILCNT_T_TYPE __UQUAD_TYPE > #define __FSFILCNT64_T_TYPE __UQUAD_TYPE > -#define __FSWORD_T_TYPE __SWORD_TYPE > +#define __FSWORD_T_TYPE __SQUAD_TYPE > -#define __CLOCK_T_TYPE __SLONGWORD_TYPE > -#define __TIME_T_TYPE __SLONGWORD_TYPE > +#define __CLOCK_T_TYPE __SQUAD_TYPE > +#define __TIME_T_TYPE __SQUAD_TYPE > #define __USECONDS_T_TYPE __U32_TYPE > -#define __SUSECONDS_T_TYPE __SLONGWORD_TYPE > +#define __SUSECONDS_T_TYPE __SQUAD_TYPE > -#define __BLKSIZE_T_TYPE __S32_TYPE > +#define __BLKSIZE_T_TYPE __SQUAD_TYPE > #define __FSID_T_TYPE struct { int __val[2]; } > #define __SSIZE_T_TYPE __SWORD_TYPE > -#define __SYSCALL_SLONG_TYPE __SLONGWORD_TYPE > -#define __SYSCALL_ULONG_TYPE __ULONGWORD_TYPE > -#define __CPU_MASK_TYPE __ULONGWORD_TYPE > +#define __SYSCALL_SLONG_TYPE __SQUAD_TYPE > +#define __SYSCALL_ULONG_TYPE __UQUAD_TYPE > +#define __CPU_MASK_TYPE __UQUAD_TYPE > > -#ifdef __LP64__ > # define __RLIM_T_MATCHES_RLIM64_T 1 > -#else > -# define __RLIM_T_MATCHES_RLIM64_T 0 > -#endif > > +#define __ASSUME_TIME64_SYSCALLS 1 > +#define __ASSUME_RLIM64_SYSCALLS 1 > > Since the sysdeps/unix/sysv/linux/generic/bits/typesizes.h definitions > generally match the kernel, anything diverging from that has the potential > of breaking it, so the difference should probably be kept to the absolute > minimum. > > I think these ones are wrong and will cause bugs similar to the clock_t > issue if they are used with kernel interfaces: > __NLINK_T_TYPE, __FSWORD_T_TYPE, __CLOCK_T_TYPE, > __BLKSIZE_T_TYPE, __SYSCALL_ULONG_TYPE, > __SYSCALL_SLONG_TYPE, __CPU_MASK_TYPE > > These are fine as long as they are only used in user space and to > wrap kernel syscalls, but I think most of them can end up being > passed to the kernel, so it seems safer not to have rv32 diverge > without a good reason. > > The remaining ones (__INO_T_TYPE, __OFF_T_TYPE, __BLKCNT_T_TYPE, > __FSBLKCNT_T_TYPE, __FSFILCNT_T_TYPE, __TIME_T_TYPE) all > follow the pattern where the kernel has an old 32-bit type and a new > 64-bit type, but the kernel tries not to expose the 32-bit interfaces > to user space on new architectures and only provide the 64-bit > replacements, but there are a couple of interfaces that never got > replaced, typically in driver and file system ioctls. > > Since glibc already has code to deal with the 64-bit types and that > is well tested, it would seem safer to me to just #undef the old > types completely rather than defining them to 64-bit, which would > make them incompatible with the kernel's types. #undef-ing these results in build failures unfortunately, it seems like they are required. I'm sending a v3 RFC to the glibc list right now. We can continue the discussion there. Alistair > > Arnd _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2019-07-17 0:06 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-07-03 0:52 [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem Alistair Francis 2019-07-03 0:52 ` Alistair Francis 2019-07-03 0:52 ` [PATCH RESEND 1/2] uapi/asm-generic: Allow defining a custom __SIGINFO struct Alistair Francis 2019-07-03 0:52 ` Alistair Francis 2019-07-03 0:52 ` [PATCH RESEND 2/2] riscv/include/uapi: Define a custom __SIGINFO struct for RV32 Alistair Francis 2019-07-03 0:52 ` Alistair Francis 2019-07-03 7:08 ` [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem Andreas Schwab 2019-07-03 7:08 ` Andreas Schwab 2019-07-03 18:40 ` Alistair Francis 2019-07-03 18:40 ` Alistair Francis 2019-07-04 7:20 ` Andreas Schwab 2019-07-04 7:20 ` Andreas Schwab 2019-07-04 9:19 ` Arnd Bergmann 2019-07-04 9:19 ` Arnd Bergmann 2019-07-17 0:02 ` Alistair Francis 2019-07-17 0:02 ` Alistair Francis
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.