LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem
@ 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
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ 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] 8+ messages in thread

* [PATCH RESEND 1/2] uapi/asm-generic: Allow defining a custom __SIGINFO struct
  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 2/2] riscv/include/uapi: Define a custom __SIGINFO struct for RV32 Alistair Francis
  2019-07-03  7:08 ` [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem Andreas Schwab
  2 siblings, 0 replies; 8+ 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	[flat|nested] 8+ messages in thread

* [PATCH RESEND 2/2] riscv/include/uapi: Define a custom __SIGINFO struct for RV32
  2019-07-03  0:52 [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem 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  7:08 ` [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem Andreas Schwab
  2 siblings, 0 replies; 8+ 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	[flat|nested] 8+ messages in thread

* Re: [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem
  2019-07-03  0:52 [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem 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 ` [PATCH RESEND 2/2] riscv/include/uapi: Define a custom __SIGINFO struct for RV32 Alistair Francis
@ 2019-07-03  7:08 ` Andreas Schwab
  2019-07-03 18:40   ` Alistair Francis
  2 siblings, 1 reply; 8+ 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] 8+ messages in thread

* Re: [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem
  2019-07-03  7:08 ` [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem Andreas Schwab
@ 2019-07-03 18:40   ` Alistair Francis
  2019-07-04  7:20     ` Andreas Schwab
  0 siblings, 1 reply; 8+ 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] 8+ 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
  2019-07-04  9:19       ` Arnd Bergmann
  0 siblings, 1 reply; 8+ 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] 8+ 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
  2019-07-17  0:02         ` Alistair Francis
  0 siblings, 1 reply; 8+ 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] 8+ 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
  0 siblings, 0 replies; 8+ 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] 8+ messages in thread

end of thread, other threads:[~2019-07-17  0:06 UTC | newest]

Thread overview: 8+ 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 ` [PATCH RESEND 1/2] uapi/asm-generic: Allow defining a custom __SIGINFO struct 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  7:08 ` [PATCH RESEND 0/2] RISC-V: Handle the siginfo_t offset problem Andreas Schwab
2019-07-03 18:40   ` Alistair Francis
2019-07-04  7:20     ` Andreas Schwab
2019-07-04  9:19       ` Arnd Bergmann
2019-07-17  0:02         ` Alistair Francis

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).