[RFC v2 00/20] RISC-V glibc port for the 32-bit

[RFC v2 00/20] RISC-V glibc port for the 32-bit

[Alistair Francis]

This patch set contains the glibc port for the 32-bit RISC-V.

This is based on all of the work that Zong Li has done [1].

Unfortunately the Linux ABI has changed since Zong Li's latest
submission. The RISC-V 32-bit (RV32) ABI no longer defines
__ARCH_WANT_TIME32_SYSCALLS which means there are no 32-bit versions of
time_t, off_t or any struct resource or system calls that use them.

To mitigate this I have set the RV32 port to use 64-bit time_t and off_t
(as is done in x86-32) and also changed the syscall imvocation to handle
the missing syscalls.

The first 3 patches are from Lukasz and have been sent upstream before
[2].

The 4th patch is a fixup required ontop of Lukasz's patches.

Patches 5 to 9 are generic ways of handling the missing syscall functions.
Patch 11 changes all RISC-V implementations to use 64-bit time_t and off_t.

I have tested this series by building a buildroot kernel and rootFS
using these glibc patches and an upstream 5.1.12 kernel for RV32. I see
hangs because of patch 8.

Patch 8 (waitid) seems to cause hangs that I haven't debugged yet, it
seems like we aren't handing the wait() functions correctly. Any help
with this would be great.

The last patch is a hack to forcefully rename the remaining system calls
that are causing compiller failures to the 64-bit versions. This is
obviously not the correct way to do this. I would like some feedback on
this series to find the upstream approved way to use the 64-bit
versions then I will extend that to these remaining functions.

The ChangeLog will need to be updated as well, so don't worry too much
about that.

Feedback on this series is very welcome!

1: https://sourceware.org/ml/libc-alpha/2018-07/msg00892.html
2: https://sourceware.org/ml/libc-alpha/2019-05/msg00661.html

RFC v2:
 - Add Lukasz's patches
 - Update the non HACK syscalls after feedback
 - define __ASSUME_TIME64_SYSCALLS and __ASSUME_RLIM64_SYSCALLS
 - Remove lockf64.c
 - Other smaller changes from RFC v1

--END---

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
 __COVER__ | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 __COVER__

diff --git a/__COVER__ b/__COVER__
new file mode 100644
index 0000000000..e69de29bb2
-- 
2.22.0



Alistair Francis (7):
  include/time.h: Fix conflicting timespec types on 32-bit
  sysdeps/nanosleep: Use clock_nanosleep_time64 if avaliable
  sysdeps/futex: Use futex_time64 if avaliable
  sysdeps/gettimeofday: Use clock_gettime64 if avaliable
  sysdeps/wait: Use waitid if avaliable
  sysdeps/getrlimit: Use prlimit64 if avaliable
  RISC-V: Use 64-bit time_t and off_t for RV32 and RV64

Lukasz Majewski (3):
  y2038: Introduce internal for glibc struct __timespec64
  y2038: Provide conversion helpers for struct __timespec64
  y2038: linux: Provide __clock_settime64 implementation

Zong Li (10):
  Documentation for the RISC-V 32-bit port
  RISC-V: Support dynamic loader for the 32-bit
  RISC-V: Add path of library directories for the 32-bit
  RISC-V: The ABI implementation for the 32-bit
  RISC-V: Hard float support for the 32 bit
  RISC-V: Regenerate ULPs of RISC-V
  RISC-V: Add ABI lists
  RISC-V: Build Infastructure for the 32-bit
  RISC-V: Fix llrint and llround missing exceptions on RV32
  Add RISC-V 32-bit target to build-many-glibcs.py

 ChangeLog                                     |  115 +
 NEWS                                          |    6 +
 README                                        |    1 +
 include/time.h                                |  119 +
 nptl/thrd_sleep.c                             |   19 +-
 scripts/build-many-glibcs.py                  |   15 +
 sysdeps/riscv/bits/wordsize.h                 |    4 +-
 sysdeps/riscv/nofpu/libm-test-ulps            |   16 +-
 sysdeps/riscv/nptl/bits/pthreadtypes-arch.h   |   25 +-
 sysdeps/riscv/preconfigure                    |    6 +-
 sysdeps/riscv/rv32/Implies-after              |    1 +
 .../riscv/rv32/fix-fp-int-convert-overflow.h  |   38 +
 sysdeps/riscv/rv32/rvd/Implies                |    3 +
 sysdeps/riscv/rv32/rvd/s_lrint.c              |   31 +
 sysdeps/riscv/rv32/rvd/s_lround.c             |   31 +
 sysdeps/riscv/rv32/rvf/Implies                |    1 +
 sysdeps/riscv/rv32/rvf/s_lrintf.c             |   31 +
 sysdeps/riscv/rv32/rvf/s_lroundf.c            |   31 +
 sysdeps/riscv/{rv64 => }/rvd/libm-test-ulps   |   56 +-
 .../riscv/{rv64 => }/rvd/libm-test-ulps-name  |    0
 sysdeps/riscv/sfp-machine.h                   |   27 +-
 sysdeps/riscv/sys/asm.h                       |    5 +-
 sysdeps/unix/sysv/linux/clock_settime.c       |   37 +-
 sysdeps/unix/sysv/linux/getrlimit.c           |    9 +
 sysdeps/unix/sysv/linux/gettimeofday.c        |   28 +
 sysdeps/unix/sysv/linux/lowlevellock-futex.h  |   28 +-
 sysdeps/unix/sysv/linux/nanosleep.c           |   12 +
 sysdeps/unix/sysv/linux/nanosleep_nocancel.c  |   11 +
 sysdeps/unix/sysv/linux/riscv/Makefile        |    4 +-
 .../unix/sysv/linux/riscv/bits/environments.h |   85 +
 sysdeps/unix/sysv/linux/riscv/bits/time64.h   |   36 +
 sysdeps/unix/sysv/linux/riscv/bits/timesize.h |   22 +
 .../unix/sysv/linux/riscv/bits/typesizes.h    |   89 +
 sysdeps/unix/sysv/linux/riscv/configure       |   39 +
 sysdeps/unix/sysv/linux/riscv/configure.ac    |    8 +
 sysdeps/unix/sysv/linux/riscv/dl-cache.h      |   17 +-
 sysdeps/unix/sysv/linux/riscv/ldconfig.h      |    2 +-
 sysdeps/unix/sysv/linux/riscv/rv32/Implies    |    3 +
 .../unix/sysv/linux/riscv/rv32/c++-types.data |   67 +
 .../sysv/linux/riscv/rv32/jmp_buf-macros.h    |   53 +
 sysdeps/unix/sysv/linux/riscv/rv32/ld.abilist |    9 +
 .../linux/riscv/rv32/libBrokenLocale.abilist  |    1 +
 .../unix/sysv/linux/riscv/rv32/libanl.abilist |    4 +
 .../unix/sysv/linux/riscv/rv32/libc.abilist   | 2101 +++++++++++++++++
 .../sysv/linux/riscv/rv32/libcrypt.abilist    |    2 +
 .../unix/sysv/linux/riscv/rv32/libdl.abilist  |    9 +
 .../unix/sysv/linux/riscv/rv32/libm.abilist   | 1021 ++++++++
 .../sysv/linux/riscv/rv32/libpthread.abilist  |  235 ++
 .../sysv/linux/riscv/rv32/libresolv.abilist   |   79 +
 .../unix/sysv/linux/riscv/rv32/librt.abilist  |   35 +
 .../linux/riscv/rv32/libthread_db.abilist     |   40 +
 .../sysv/linux/riscv/rv32/libutil.abilist     |    6 +
 sysdeps/unix/sysv/linux/riscv/shlib-versions  |   10 +-
 sysdeps/unix/sysv/linux/wait.c                |   21 +-
 sysdeps/unix/sysv/linux/waitpid.c             |   54 +
 sysdeps/unix/sysv/linux/waitpid_nocancel.c    |   53 +
 56 files changed, 4745 insertions(+), 66 deletions(-)
 create mode 100644 sysdeps/riscv/rv32/Implies-after
 create mode 100644 sysdeps/riscv/rv32/fix-fp-int-convert-overflow.h
 create mode 100644 sysdeps/riscv/rv32/rvd/Implies
 create mode 100644 sysdeps/riscv/rv32/rvd/s_lrint.c
 create mode 100644 sysdeps/riscv/rv32/rvd/s_lround.c
 create mode 100644 sysdeps/riscv/rv32/rvf/Implies
 create mode 100644 sysdeps/riscv/rv32/rvf/s_lrintf.c
 create mode 100644 sysdeps/riscv/rv32/rvf/s_lroundf.c
 rename sysdeps/riscv/{rv64 => }/rvd/libm-test-ulps (98%)
 rename sysdeps/riscv/{rv64 => }/rvd/libm-test-ulps-name (100%)
 create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/environments.h
 create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/time64.h
 create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/timesize.h
 create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/Implies
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/c++-types.data
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/jmp_buf-macros.h
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/ld.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libBrokenLocale.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libanl.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libc.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libcrypt.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libdl.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libm.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libpthread.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libresolv.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/librt.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libthread_db.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libutil.abilist

-- 
2.22.0

[RFC v2 01/20] y2038: Introduce internal for glibc struct __timespec64

[Alistair Francis]

From: Lukasz Majewski <lukma@denx.de>

This type is a glibc's type similar to struct timespec but whose tv_sec
field is a __time64_t rather than a time_t, which makes it Y2038-proof and
usable to pass syscalls between user code and Y2038-proof kernel.

To support passing this structure to the kernel - the tv_pad, 32 bit int,
has been introduced. The placement of it depends on endianness of the SoC.

Tested on x86_64 and ARM.

* include/time.h: Add struct __timespec64 definition
---
 include/time.h | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/include/time.h b/include/time.h
index ac3163c2a5..33d0fcb0fe 100644
--- a/include/time.h
+++ b/include/time.h
@@ -5,6 +5,7 @@
 # include <bits/types/locale_t.h>
 # include <stdbool.h>
 # include <time/mktime-internal.h>
+# include <endian.h>
 
 extern __typeof (strftime_l) __strftime_l;
 libc_hidden_proto (__strftime_l)
@@ -51,6 +52,30 @@ extern void __tzset_parse_tz (const char *tz) attribute_hidden;
 extern void __tz_compute (__time64_t timer, struct tm *tm, int use_localtime)
   __THROW attribute_hidden;
 
+#if __WORDSIZE == 64 \
+  || (defined __SYSCALL_WORDSIZE && __SYSCALL_WORDSIZE == 64)
+# define __timespec64 timespec
+#else
+/* The glibc Y2038-proof struct __timespec64 structure for a time value.
+   To keep things Posix-ish, we keep the nanoseconds field a 32-bit
+   signed long, but since the Linux field is a 64-bit signed int, we
+   pad our tv_nsec with a 32-bit int.
+
+   As a general rule the Linux kernel is ignoring upper 32 bits of
+   tv_nsec field.  */
+struct __timespec64
+{
+  __time64_t tv_sec;         /* Seconds */
+# if BYTE_ORDER == BIG_ENDIAN
+  __int32_t tv_pad;          /* Padding */
+  __int32_t tv_nsec;         /* Nanoseconds */
+# else
+  __int32_t tv_nsec;         /* Nanoseconds */
+  __int32_t tv_pad;          /* Padding */
+# endif
+};
+#endif
+
 #if __TIMESIZE == 64
 # define __ctime64 ctime
 #else
-- 
2.22.0

[RFC v2 02/20] y2038: Provide conversion helpers for struct __timespec64

[Alistair Francis]

From: Lukasz Majewski <lukma@denx.de>

Those functions allow easy conversion between Y2038 safe struct
__timespec64 and other time related data structures (like struct timeval).

Moreover, those functions are NOT compiled when 64 bit time support is
enabled (i.e. the __ASSUME_TIME64_SYSCALLS is defined) and are used only
in 32 bit wrappers (like e.g. __clock_settime()).

* include/time.h (valid_timeval_to_timespec64): Add.
* include/time.h (valid_timespec_to_timespec64): Likewise.
* include/time.h (valid_timespec64_to_timespec): Likewise.
* include/time.h (valid_timespec64_to_timeval): Likewise.
* include/time.h (IS_VALID_NANOSECONDS): Likewise.
* include/time.h (timespec_to_timespec64): Likewise.
* include/time.h (timespec64_to_timespec): Likewise.
* include/time.h (timespec64_to_timeval): Likewise.
---
 include/time.h | 85 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 85 insertions(+)

diff --git a/include/time.h b/include/time.h
index 33d0fcb0fe..1b38d019c8 100644
--- a/include/time.h
+++ b/include/time.h
@@ -181,5 +181,90 @@ in_time_t_range (__time64_t t)
   return s == t;
 }
 
+# ifndef __ASSUME_TIME64_SYSCALLS
+/* Convert a known valid struct timeval into a struct __timespec64.  */
+static inline void
+valid_timeval_to_timespec64 (const struct timeval *tv32,
+			     struct __timespec64 *ts64)
+{
+  ts64->tv_sec = tv32->tv_sec;
+  ts64->tv_nsec = tv32->tv_usec * 1000;
+}
+
+/* Convert a known valid struct timespec into a struct __timespec64.  */
+static inline void
+valid_timespec_to_timespec64 (const struct timespec *ts32,
+			      struct __timespec64 *ts64)
+{
+  ts64->tv_sec = ts32->tv_sec;
+  ts64->tv_nsec = ts32->tv_nsec;
+}
+
+/* Convert a known valid struct __timespec64 into a struct timespec.  */
+static inline void
+valid_timespec64_to_timespec (const struct __timespec64 *ts64,
+			      struct timespec *ts32)
+{
+  ts32->tv_sec = (time_t) ts64->tv_sec;
+  ts32->tv_nsec = ts64->tv_nsec;
+}
+
+/* Convert a known valid struct __timespec64 into a struct timeval.  */
+static inline void
+valid_timespec64_to_timeval (const struct __timespec64 *ts64,
+			     struct timeval *tv32)
+{
+  tv32->tv_sec = (time_t) ts64->tv_sec;
+  tv32->tv_usec = ts64->tv_nsec / 1000;
+}
+
+/* Check if a value lies with the valid nanoseconds range.  */
+#define IS_VALID_NANOSECONDS(ns) ((ns) >= 0 && (ns) <= 999999999)
+
+/* Check and convert a struct timespec into a struct __timespec64.  */
+static inline bool
+timespec_to_timespec64 (const struct timespec *ts32,
+                        struct __timespec64 *ts64)
+{
+  /* Check that ts32 holds a valid count of nanoseconds.  */
+  if (! IS_VALID_NANOSECONDS (ts32->tv_nsec))
+    return false;
+  /* All ts32 fields can fit in ts64, so copy them.  */
+  valid_timespec_to_timespec64 (ts32, ts64);
+  return true;
+}
+
+/* Check and convert a struct __timespec64 into a struct timespec.  */
+static inline bool
+timespec64_to_timespec (const struct __timespec64 *ts64,
+                        struct timespec *ts32)
+{
+  /* Check that tv_nsec holds a valid count of nanoseconds.  */
+  if (! IS_VALID_NANOSECONDS (ts64->tv_nsec))
+    return false;
+  /* Check that tv_sec can fit in a __time_t.  */
+  if (! in_time_t_range (ts64->tv_sec))
+    return false;
+  /* All ts64 fields can fit in ts32, so copy them.  */
+  valid_timespec64_to_timespec (ts64, ts32);
+  return true;
+}
+
+/* Check and convert a struct __timespec64 into a struct timeval.  */
+static inline bool
+timespec64_to_timeval (const struct __timespec64 *ts64,
+                       struct timeval *tv32)
+{
+  /* Check that tv_nsec holds a valid count of nanoseconds.  */
+  if (! IS_VALID_NANOSECONDS (ts64->tv_nsec))
+    return false;
+  /* Check that tv_sec can fit in a __time_t.  */
+  if (! in_time_t_range (ts64->tv_sec))
+    return false;
+  /* All ts64 fields can fit in tv32, so copy them.  */
+  valid_timespec64_to_timeval (ts64, tv32);
+  return true;
+}
+# endif
 #endif
 #endif
-- 
2.22.0

[RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Alistair Francis]

From: Lukasz Majewski <lukma@denx.de>

This patch provides new __clock_settime64 explicit 64 bit function for
setting the time. Moreover, a 32 bit version - __clock_settime - has been
refactored to internally use __clock_settime64.

The __clock_settime is now supposed to be used on systems still supporting
32 bit time (__TIMESIZE != 64) - hence the necessary conversion to 64 bit
struct timespec.

The new clock_settime64 syscall available from Linux 5.1+ has been used,
when applicable.

The __ASSUME_TIME64_SYSCALLS flag indicates if the Linux kernel supports
64 bit version of clock_settime (i.e. clock_settime64).
If this flag is not defined, the fallback with legacy clock_settime
supporting 32 bit time is used.

When working on 32 bit systems without Y2038 time support the
clock_settime64 returns error when one wants to set time with wrong
(overflowed) tv_sec value. Moreover, the correctness of tv_nsec is also
checked.

In this patch the internal padding (tv_pad) of struct __timespec64 is
left untouched (on systems with __WORDSIZE == 32) as Linux kernel ignores
upper 32 bits of tv_nsec.

Tests:
- The code has been tested with x86_64/x86 (native compilation):
make PARALLELMFLAGS="-j8" && make xcheck PARALLELMFLAGS="-j8"

- Run specific tests on ARM/x86 32bit systems (qemu):
https://github.com/lmajewski/meta-y2038
and run tests:
https://github.com/lmajewski/y2038-tests/commits/master
on kernels with and without 64 bit time support.

No regressions were observed.

* include/time.h (__clock_settime64):
  Add __clock_settime alias according to __TIMESIZE define
* sysdeps/unix/sysv/linux/clock_settime.c (__clock_settime):
  Refactor this function to be used only on 32 bit machines as a wrapper
  on __clock_settime64.
* sysdeps/unix/sysv/linux/clock_settime.c (__clock_settime64): Add
* sysdeps/unix/sysv/linux/clock_settime.c (__clock_settime64):
  Use clock_settime64 kernel syscall (available from 5.1-rc1+ Linux)
---
 include/time.h                          |  8 ++++++
 sysdeps/unix/sysv/linux/clock_settime.c | 37 ++++++++++++++++++++++---
 2 files changed, 41 insertions(+), 4 deletions(-)

diff --git a/include/time.h b/include/time.h
index 1b38d019c8..7155b2e4db 100644
--- a/include/time.h
+++ b/include/time.h
@@ -127,6 +127,14 @@ extern __time64_t __timegm64 (struct tm *__tp) __THROW;
 libc_hidden_proto (__timegm64)
 #endif
 
+#if __TIMESIZE == 64
+# define __clock_settime64 __clock_settime
+#else
+extern int __clock_settime64 (clockid_t clock_id,
+                              const struct __timespec64 *tp);
+libc_hidden_proto (__clock_settime64)
+#endif
+
 /* Compute the `struct tm' representation of T,
    offset OFFSET seconds east of UTC,
    and store year, yday, mon, mday, wday, hour, min, sec into *TP.
diff --git a/sysdeps/unix/sysv/linux/clock_settime.c b/sysdeps/unix/sysv/linux/clock_settime.c
index d837e3019c..7274f01846 100644
--- a/sysdeps/unix/sysv/linux/clock_settime.c
+++ b/sysdeps/unix/sysv/linux/clock_settime.c
@@ -19,11 +19,9 @@
 #include <sysdep.h>
 #include <time.h>
 
-#include "kernel-posix-cpu-timers.h"
-
 /* Set CLOCK to value TP.  */
 int
-__clock_settime (clockid_t clock_id, const struct timespec *tp)
+__clock_settime64 (clockid_t clock_id, const struct __timespec64 *tp)
 {
   /* Make sure the time cvalue is OK.  */
   if (tp->tv_nsec < 0 || tp->tv_nsec >= 1000000000)
@@ -32,6 +30,37 @@ __clock_settime (clockid_t clock_id, const struct timespec *tp)
       return -1;
     }
 
-  return INLINE_SYSCALL_CALL (clock_settime, clock_id, tp);
+#ifdef __ASSUME_TIME64_SYSCALLS
+# ifndef __NR_clock_settime64
+#  define __NR_clock_settime64 __NR_clock_settime
+# endif
+  return INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
+#else
+# ifdef __NR_clock_settime64
+  int ret = INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
+  if (ret == 0 || errno != ENOSYS)
+    return ret;
+# endif
+  if (! in_time_t_range (tp->tv_sec))
+    {
+      __set_errno (EOVERFLOW);
+      return -1;
+    }
+
+  struct timespec ts32;
+  valid_timespec64_to_timespec (tp, &ts32);
+  return INLINE_SYSCALL_CALL (clock_settime, clock_id, &ts32);
+#endif
 }
 weak_alias (__clock_settime, clock_settime)
+
+#if __TIMESIZE != 64
+int
+__clock_settime (clockid_t clock_id, const struct timespec *tp)
+{
+  struct __timespec64 ts64;
+
+  valid_timespec_to_timespec64 (tp, &ts64);
+  return __clock_settime64 (clock_id, &ts64);
+}
+#endif
-- 
2.22.0

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Arnd Bergmann]

On Tue, Jun 25, 2019 at 2:11 AM Alistair Francis
<alistair.francis@wdc.com> wrote:

>  weak_alias (__clock_settime, clock_settime)
> +
> +#if __TIMESIZE != 64
> +int
> +__clock_settime (clockid_t clock_id, const struct timespec *tp)
> +{
> +  struct __timespec64 ts64;
> +
> +  valid_timespec_to_timespec64 (tp, &ts64);
> +  return __clock_settime64 (clock_id, &ts64);
> +}
> +#endif

I missed this when Lukasz first posted this, but I would still
prefer this to be changed.

Having clock_settime() (using the weak_alias) call into
__clock_settime64() means that a kernel that warns about
old user space calling into the old syscall never notices this.

Can you please leave the existing clock_settime()
untouched and instead just change the internal callers
(if any) over to __clock_settime64?

      Arnd

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 2117 bytes --]

Hi Arnd,

> On Tue, Jun 25, 2019 at 2:11 AM Alistair Francis
> <alistair.francis@wdc.com> wrote:
> 
> >  weak_alias (__clock_settime, clock_settime)
> > +
> > +#if __TIMESIZE != 64
> > +int
> > +__clock_settime (clockid_t clock_id, const struct timespec *tp)
> > +{
> > +  struct __timespec64 ts64;
> > +
> > +  valid_timespec_to_timespec64 (tp, &ts64);
> > +  return __clock_settime64 (clock_id, &ts64);
> > +}
> > +#endif  
> 
> I missed this when Lukasz first posted this, but I would still
> prefer this to be changed.
> 
> Having clock_settime() (using the weak_alias) call into
> __clock_settime64() means that a kernel that warns about
> old user space calling into the old syscall never notices this.

Could you be more specific here?


I thought that we do not care about the legacy systems (i.e. those
which don't switch to 64 bit time syscalls before Y2038).

The assumption is to not break anything and use 64 bit time related
syscalls after v5.1 kernel (i.e. clock_settime64 and friends on systems
with __WORDSIZE=32).

Syscalls, which handle only 32 bit time would be used as fallback.

> 
> Can you please leave the existing clock_settime()

I think that some pseudo code would shed some more light on your idea.

> untouched and instead just change the internal callers
> (if any) over to __clock_settime64?

The above approach (from this patch) was developed to comply with
following recommendations:

https://www.gnu.org/software/libc/manual/html_mono/libc.html
"D.2.1 64-bit time symbol handling in the GNU C Library"
to convert *clock_settime*.

and most notably from:
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#clock_gettime.28.29
recommended by glibc for the syscalls conversion for 64 bit.

It also uses the __ASSUME_TIME64_SYSCALLS flag.

> 
>       Arnd




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Arnd Bergmann]

On Tue, Jun 25, 2019 at 5:51 PM Lukasz Majewski <lukma@denx.de> wrote:
> > On Tue, Jun 25, 2019 at 2:11 AM Alistair Francis
> > <alistair.francis@wdc.com> wrote:
> >
> > >  weak_alias (__clock_settime, clock_settime)
> > > +
> > > +#if __TIMESIZE != 64
> > > +int
> > > +__clock_settime (clockid_t clock_id, const struct timespec *tp)
> > > +{
> > > +  struct __timespec64 ts64;
> > > +
> > > +  valid_timespec_to_timespec64 (tp, &ts64);
> > > +  return __clock_settime64 (clock_id, &ts64);
> > > +}
> > > +#endif
> >
> > I missed this when Lukasz first posted this, but I would still
> > prefer this to be changed.
> >
> > Having clock_settime() (using the weak_alias) call into
> > __clock_settime64() means that a kernel that warns about
> > old user space calling into the old syscall never notices this.
>
> Could you be more specific here?
>
>
> I thought that we do not care about the legacy systems (i.e. those
> which don't switch to 64 bit time syscalls before Y2038).
>
> The assumption is to not break anything and use 64 bit time related
> syscalls after v5.1 kernel (i.e. clock_settime64 and friends on systems
> with __WORDSIZE=32).
>
> Syscalls, which handle only 32 bit time would be used as fallback.

I don't mind falling back on the 32-bit implementation from a time64 syscall
when running on the old kernel, that part is required to make new binaries
run on pre-5.1 kernel.

Your __clock_settime however does the reverse: you have an application
that calls clock_settime(), the alias redirects that to __clock_settime(),
and that converts it into the 64-bit structure and passes it into
__clock_settime64(), which then calls the time64 syscall before falling
back to calling the time32 syscall.

This is problematic in the scenario that you have an embedded system
you deploy today, and turn off the time32 syscalls in the kernel.
All applications are built against the time64 glibc interfaces, except
for one tool that someone forgot. This calls the old clock_settime()
with a 32-bit time, which gets converted into and passed into
clock_settime64 in the kernel where it successfully sets the time at
boot.

In 2038, it stops working because of the time_t overflow that was
not caught during validation. If we call the time32 interface here, it
breaks immediately on kernels that return -ENOSYS from
clock_gettime(), which makes the validation easier and more reliable.

> > Can you please leave the existing clock_settime()
>
> I think that some pseudo code would shed some more light on your idea.

What I mean is to have

#ifdef __NR_clock_settime
int
__clock_settime (clockid_t clock_id, const struct timespec *tp)
{
  return INLINE_SYSCALL_CALL (clock_settime, clock_id, tp);
}
#endif

This will do the right thing on 64-bit architectures (which use time64
always), on new 32-bit architectures (not provide __clock_settime
at all, clock_settime() should be an alias for __clock_settime64())
and on old 32-bit architectures (work as expected on existing
kernels, fail with -ENOSYS when we want it to).

> and most notably from:
> https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#clock_gettime.28.29
> recommended by glibc for the syscalls conversion for 64 bit.
>
> It also uses the __ASSUME_TIME64_SYSCALLS flag.

I thought it was covered in there, but maybe that changed.

      Arnd

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 5705 bytes --]

Hi Arnd,

> On Tue, Jun 25, 2019 at 5:51 PM Lukasz Majewski <lukma@denx.de> wrote:
> > > On Tue, Jun 25, 2019 at 2:11 AM Alistair Francis
> > > <alistair.francis@wdc.com> wrote:
> > >  
> > > >  weak_alias (__clock_settime, clock_settime)
> > > > +
> > > > +#if __TIMESIZE != 64
> > > > +int
> > > > +__clock_settime (clockid_t clock_id, const struct timespec *tp)
> > > > +{
> > > > +  struct __timespec64 ts64;
> > > > +
> > > > +  valid_timespec_to_timespec64 (tp, &ts64);
> > > > +  return __clock_settime64 (clock_id, &ts64);
> > > > +}
> > > > +#endif  
> > >
> > > I missed this when Lukasz first posted this, but I would still
> > > prefer this to be changed.
> > >
> > > Having clock_settime() (using the weak_alias) call into
> > > __clock_settime64() means that a kernel that warns about
> > > old user space calling into the old syscall never notices this.  
> >
> > Could you be more specific here?
> >
> >
> > I thought that we do not care about the legacy systems (i.e. those
> > which don't switch to 64 bit time syscalls before Y2038).
> >
> > The assumption is to not break anything and use 64 bit time related
> > syscalls after v5.1 kernel (i.e. clock_settime64 and friends on
> > systems with __WORDSIZE=32).
> >
> > Syscalls, which handle only 32 bit time would be used as fallback.  
> 
> I don't mind falling back on the 32-bit implementation from a time64
> syscall when running on the old kernel, that part is required to make
> new binaries run on pre-5.1 kernel.
> 
> Your __clock_settime however does the reverse: you have an application
> that calls clock_settime(), the alias redirects that to
> __clock_settime(), and that converts it into the 64-bit structure and
> passes it into __clock_settime64(), which then calls the time64
> syscall before falling back to calling the time32 syscall.

This patch focuses on the situation where we strive to provide/use 64
bit time support and try not to rely on 32 bit interfaces.

> 
> This is problematic in the scenario that you have an embedded system
> you deploy today, and turn off the time32 syscalls in the kernel.

I assume that then we would only have __NR_clock_settime64 defined (no
__NR_clock_settime available) on WORDSIZE==32 archs?

> All applications are built against the time64 glibc interfaces, except
> for one tool that someone forgot. This calls the old clock_settime()
> with a 32-bit time, which gets converted into and passed into
> clock_settime64 in the kernel where it successfully sets the time at
> boot.

Interesting use case. Thanks for sharing it.

> 
> In 2038, it stops working because of the time_t overflow that was
> not caught during validation. If we call the time32 interface here, it
> breaks immediately on kernels that return -ENOSYS from
> clock_gettime(), 

Maybe I'm not aware of something, but isn't the removal of
clock_settime syscall supporting only 32 bit time (on archs with
WORDSIZE==32) the ABI break?

Shouldn't those syscalls be kept until the minimal supported glibc
kernel version is 5.1?

> which makes the validation easier and more reliable.
> 
> > > Can you please leave the existing clock_settime()  
> >
> > I think that some pseudo code would shed some more light on your
> > idea.  
> 
> What I mean is to have
> 
> #ifdef __NR_clock_settime
> int
> __clock_settime (clockid_t clock_id, const struct timespec *tp)
> {
>   return INLINE_SYSCALL_CALL (clock_settime, clock_id, tp);
> }
> #endif
> 
> This will do the right thing on 64-bit architectures (which use time64
> always), on new 32-bit architectures (not provide __clock_settime
> at all, clock_settime() should be an alias for __clock_settime64())
> and on old 32-bit architectures (work as expected on existing
> kernels, fail with -ENOSYS when we want it to).
> 

The latest patch for clock_settime [1]:
Could be changed to:

#if __TIMESIZE != 64
int
__clock_settime (clockid_t clock_id, const struct timespec *tp)
{
/* For WORDSIZE==32 systems the headers could still have defined
__NR_clock_settime, but the kernel itself may not support it anymore */
#ifdef __NR_clock_settime
  return INLINE_SYSCALL_CALL (clock_settime, clock_id, tp);
#endif

  struct __timespec64 ts64;

  valid_timespec_to_timespec64 (tp, &ts64);
  return __clock_settime64 (clock_id, &ts64);
}
#endif


However, there is the problem that in some point in time the glibc will
switch to 64 bit __TIMESIZE only (probably when minimal kernel version
for glibc would be grater than 5.1) and all __clock_settime syscalls
would be served with __clock_settime64 (as 64 bit time support is
always in place).

After this switch the "unconverted" program will setup wrong time.


> > and most notably from:
> > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#clock_gettime.28.29
> > recommended by glibc for the syscalls conversion for 64 bit.
> >
> > It also uses the __ASSUME_TIME64_SYSCALLS flag.  
> 
> I thought it was covered in there, but maybe that changed.

This flag is supposed to indicate if the kernel supports 64 bit time
interface (either with clock_settime syscall on WORDSIZE==64 or
clock_settime64 on WORDSIZE==32, including x32).

The newest proposition for it: [2] 

> 
>       Arnd


Note:

[1] - https://patchwork.ozlabs.org/patch/1107235/
[2] - https://patchwork.ozlabs.org/patch/1117100/



Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Arnd Bergmann]

On Wed, Jun 26, 2019 at 11:07 AM Lukasz Majewski <lukma@denx.de> wrote:
> > On Tue, Jun 25, 2019 at 5:51 PM Lukasz Majewski <lukma@denx.de> wrote:
> > > > On Tue, Jun 25, 2019 at 2:11 AM Alistair Francis <alistair.francis@wdc.com> wrote:
> > This is problematic in the scenario that you have an embedded system
> > you deploy today, and turn off the time32 syscalls in the kernel.
>
> I assume that then we would only have __NR_clock_settime64 defined (no
> __NR_clock_settime available) on WORDSIZE==32 archs?

No, the kernel header files are generated independently of the configuration.
The macro would still be there at compile-time, but depending on kernel
configuration, the system call would return -ENOSYS, same way we do
for other optional system calls.

> > In 2038, it stops working because of the time_t overflow that was
> > not caught during validation. If we call the time32 interface here, it
> > breaks immediately on kernels that return -ENOSYS from
> > clock_gettime(),
>
> Maybe I'm not aware of something, but isn't the removal of
> clock_settime syscall supporting only 32 bit time (on archs with
> WORDSIZE==32) the ABI break?
>
> Shouldn't those syscalls be kept until the minimal supported glibc
> kernel version is 5.1?

We will probably keep them as an option in the kernel until 2038,
but leave it to the distro or embedded system design to turn them
on or off. Most of the remaining general-purpose distros (Ubuntu
just said they'd stop theirs, others are likely to follow) are likely to
leave them on for compatibility, while embedded systems with
projected life times beyond 2038 should turn them off.

The minimal kernel version supported by glibc doesn't matter
to the kernel, as kernels support older C libraries going back
to the beginning, just like newer glibc versions support
applications linked against earlier glibc versions.

> The latest patch for clock_settime [1]:
> Could be changed to:
>
> #if __TIMESIZE != 64
> int
> __clock_settime (clockid_t clock_id, const struct timespec *tp)
> {
> /* For WORDSIZE==32 systems the headers could still have defined
> __NR_clock_settime, but the kernel itself may not support it anymore */
> #ifdef __NR_clock_settime
>   return INLINE_SYSCALL_CALL (clock_settime, clock_id, tp);
> #endif
>
>   struct __timespec64 ts64;
>
>   valid_timespec_to_timespec64 (tp, &ts64);
>   return __clock_settime64 (clock_id, &ts64);
> }
> #endif

The "#ifdef __NR_clock_settime" is always true when __TIMESIZE != 64,
so that could be simplified to the version I suggested.

> However, there is the problem that in some point in time the glibc will
> switch to 64 bit __TIMESIZE only (probably when minimal kernel version
> for glibc would be grater than 5.1) and all __clock_settime syscalls
> would be served with __clock_settime64 (as 64 bit time support is
> always in place).
>
> After this switch the "unconverted" program will setup wrong time.

I don't understand. What does it mean to switch to __TIMESIZE=64?
Would that not break all existing binaries regardless of the implementation?

I would expect that the only thing changing after the minimum
kernel version is updated is the fallback from the public time64
interfaces to the time32 system calls, but glibc cannot drop the
public time32 interfaces as long as someone might be using those,
i.e. just before the 2038 overflow. In no case would an existing
lilbrary symbol change the data type of its arguments though.

Between adding the time64 system calls (now) and removing
the time32 system calls (in y2038), there are a couple of
intermediate steps that can be years apart, or all happen
at the same time:

- drop support for building with pre-5.1 kernel headers
- stop running on pre-5.1 kernels
- change the default for newly compiled code to time64
- drop support for building with time32

      Arnd

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 5372 bytes --]

Hi Arnd,

> On Wed, Jun 26, 2019 at 11:07 AM Lukasz Majewski <lukma@denx.de>
> wrote:
> > > On Tue, Jun 25, 2019 at 5:51 PM Lukasz Majewski <lukma@denx.de>
> > > wrote:  
> > > > > On Tue, Jun 25, 2019 at 2:11 AM Alistair Francis
> > > > > <alistair.francis@wdc.com> wrote:  
> > > This is problematic in the scenario that you have an embedded
> > > system you deploy today, and turn off the time32 syscalls in the
> > > kernel.  
> >
> > I assume that then we would only have __NR_clock_settime64 defined
> > (no __NR_clock_settime available) on WORDSIZE==32 archs?  
> 
> No, the kernel header files are generated independently of the
> configuration. The macro would still be there at compile-time, but
> depending on kernel configuration, the system call would return
> -ENOSYS, same way we do for other optional system calls.
> 
> > > In 2038, it stops working because of the time_t overflow that was
> > > not caught during validation. If we call the time32 interface
> > > here, it breaks immediately on kernels that return -ENOSYS from
> > > clock_gettime(),  
> >
> > Maybe I'm not aware of something, but isn't the removal of
> > clock_settime syscall supporting only 32 bit time (on archs with
> > WORDSIZE==32) the ABI break?
> >
> > Shouldn't those syscalls be kept until the minimal supported glibc
> > kernel version is 5.1?  
> 
> We will probably keep them as an option in the kernel until 2038,
> but leave it to the distro or embedded system design to turn them
> on or off.

Isn't this the ABI break on demand ?

> Most of the remaining general-purpose distros (Ubuntu
> just said they'd stop theirs, others are likely to follow) are likely
> to leave them on for compatibility, while embedded systems with
> projected life times beyond 2038 should turn them off.
> 
> The minimal kernel version supported by glibc doesn't matter
> to the kernel, as kernels support older C libraries going back
> to the beginning, just like newer glibc versions support
> applications linked against earlier glibc versions.
> 
> > The latest patch for clock_settime [1]:
> > Could be changed to:
> >
> > #if __TIMESIZE != 64
> > int
> > __clock_settime (clockid_t clock_id, const struct timespec *tp)
> > {
> > /* For WORDSIZE==32 systems the headers could still have defined
> > __NR_clock_settime, but the kernel itself may not support it
> > anymore */ #ifdef __NR_clock_settime
> >   return INLINE_SYSCALL_CALL (clock_settime, clock_id, tp);
> > #endif
> >
> >   struct __timespec64 ts64;
> >
> >   valid_timespec_to_timespec64 (tp, &ts64);
> >   return __clock_settime64 (clock_id, &ts64);
> > }
> > #endif  
> 
> The "#ifdef __NR_clock_settime" is always true when __TIMESIZE != 64,
> so that could be simplified to the version I suggested.

For following setup: WORDSIZE=32, TIMESIZE=32 and kernel with
__NR_clock_settime returning -ENOSYS (disabled by embedded system
designer in the kernel), but supporting __NR_clock_settime64 (for
example 32 bit ARM):

The policy question - shall the user space binary after calling
clock_settime:

1. Receive -ENOSYS as the __NR_clock_settime was used to fulfill the
request

or

2. Receive 0 (operation succeed) as the available __NR_clock_settime64
has been used to perform the requested operation.


For the proposed patch (clock_settime) - the option 2 is now performed.


> 
> > However, there is the problem that in some point in time the glibc
> > will switch to 64 bit __TIMESIZE only (probably when minimal kernel
> > version for glibc would be grater than 5.1) and all __clock_settime
> > syscalls would be served with __clock_settime64 (as 64 bit time
> > support is always in place).
> >
> > After this switch the "unconverted" program will setup wrong time.  
> 
> I don't understand. What does it mean to switch to __TIMESIZE=64?
> Would that not break all existing binaries regardless of the
> implementation?

__TIMESIZE represents the size of time_t (the glibc internal time
representation). This change would be probably performed in the future
after the _TIME_BITS==64 is defined by default.

However, I do not feel competent enough to speak about glibc long term
plans.

> 
> I would expect that the only thing changing after the minimum
> kernel version is updated is the fallback from the public time64
> interfaces to the time32 system calls, but glibc cannot drop the
> public time32 interfaces as long as someone might be using those,
> i.e. just before the 2038 overflow. In no case would an existing
> lilbrary symbol change the data type of its arguments though.

Yes, correct. 

> 
> Between adding the time64 system calls (now) and removing
> the time32 system calls (in y2038), there are a couple of
> intermediate steps that can be years apart, or all happen
> at the same time:
> 
> - drop support for building with pre-5.1 kernel headers
> - stop running on pre-5.1 kernels
> - change the default for newly compiled code to time64
> - drop support for building with time32
> 
>       Arnd




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Florian Weimer]

* Lukasz Majewski:

> Hi Arnd,
>
>> We will probably keep them as an option in the kernel until 2038,
>> but leave it to the distro or embedded system design to turn them
>> on or off.
>
> Isn't this the ABI break on demand ?

Yes, it is.  It happened with vsyscall, too.

Stuff like that is only feasible if you expect that a dynamically linked
libc is the ultimate ABI boundary for applications.  I don't think
that's realistic or actually intended, especially for things like
futexes.

> For following setup: WORDSIZE=32, TIMESIZE=32 and kernel with
> __NR_clock_settime returning -ENOSYS (disabled by embedded system
> designer in the kernel), but supporting __NR_clock_settime64 (for
> example 32 bit ARM):
>
> The policy question - shall the user space binary after calling
> clock_settime:
>
> 1. Receive -ENOSYS as the __NR_clock_settime was used to fulfill the
> request
>
> or
>
> 2. Receive 0 (operation succeed) as the available __NR_clock_settime64
> has been used to perform the requested operation.
>
>
> For the proposed patch (clock_settime) - the option 2 is now performed.

In my opinion, an existing 32-bit architecture which does not provide
the clock_settime system call (that it has provided before) is just
broken, and will be so at least until 2038.

We can add the fallback code in glibc, but that will only give people
the wrong idea that they can disable the 32-bit system calls.  It's just
not true.

Thanks,
Florian

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 1986 bytes --]

Hi Florian,

> * Lukasz Majewski:
> 
> > Hi Arnd,
> >  
> >> We will probably keep them as an option in the kernel until 2038,
> >> but leave it to the distro or embedded system design to turn them
> >> on or off.  
> >
> > Isn't this the ABI break on demand ?  
> 
> Yes, it is.  It happened with vsyscall, too.
> 
> Stuff like that is only feasible if you expect that a dynamically
> linked libc is the ultimate ABI boundary for applications.  I don't
> think that's realistic or actually intended, especially for things
> like futexes.
> 
> > For following setup: WORDSIZE=32, TIMESIZE=32 and kernel with
> > __NR_clock_settime returning -ENOSYS (disabled by embedded system
> > designer in the kernel), but supporting __NR_clock_settime64 (for
> > example 32 bit ARM):
> >
> > The policy question - shall the user space binary after calling
> > clock_settime:
> >
> > 1. Receive -ENOSYS as the __NR_clock_settime was used to fulfill the
> > request
> >
> > or
> >
> > 2. Receive 0 (operation succeed) as the available
> > __NR_clock_settime64 has been used to perform the requested
> > operation.
> >
> >
> > For the proposed patch (clock_settime) - the option 2 is now
> > performed.  
> 
> In my opinion, an existing 32-bit architecture which does not provide
> the clock_settime system call (that it has provided before) is just
> broken, and will be so at least until 2038.

Am I correct, that you opt for first option that glibc shall return
just -ENOSYS in that case?


> 
> We can add the fallback code in glibc, but that will only give people
> the wrong idea that they can disable the 32-bit system calls.  It's
> just not true.
> 
> Thanks,
> Florian




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Florian Weimer]

* Lukasz Majewski:

>> In my opinion, an existing 32-bit architecture which does not provide
>> the clock_settime system call (that it has provided before) is just
>> broken, and will be so at least until 2038.
>
> Am I correct, that you opt for first option that glibc shall return
> just -ENOSYS in that case?

I think it's undefined.  For clock_settime, the only useful outcome is
-1 with errno set to ENOSYS.  However, there are some system calls which
cannot really fail (time, for instance), and there I would say that
behavior is simply undefined.

Thanks,
Florian

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]

Hi Florian,

> * Lukasz Majewski:
> 
> >> In my opinion, an existing 32-bit architecture which does not
> >> provide the clock_settime system call (that it has provided
> >> before) is just broken, and will be so at least until 2038.  
> >
> > Am I correct, that you opt for first option that glibc shall return
> > just -ENOSYS in that case?  
> 
> I think it's undefined.  For clock_settime, the only useful outcome is
> -1 with errno set to ENOSYS.  However, there are some system calls
> which cannot really fail (time, for instance), and there I would say
> that behavior is simply undefined.

Ok. I see. So the clock_settime syscall shall return from glibc with -1
and errno set to ENOSYS (I shall NOT try to set the time with
clock_settime64 bit syscall in this case).

Thanks for explanation, appreciated.

> 
> Thanks,
> Florian




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Arnd Bergmann]

On Wed, Jun 26, 2019 at 5:03 PM Lukasz Majewski <lukma@denx.de> wrote:
> > On Wed, Jun 26, 2019 at 11:07 AM Lukasz Majewski <lukma@denx.de> wrote:
> > > > On Tue, Jun 25, 2019 at 5:51 PM Lukasz Majewski <lukma@denx.de>
> > >
> > > Shouldn't those syscalls be kept until the minimal supported glibc
> > > kernel version is 5.1?
> >
> > We will probably keep them as an option in the kernel until 2038,
> > but leave it to the distro or embedded system design to turn them
> > on or off.
>
> Isn't this the ABI break on demand ?

It's removing an unused ABI in order to ensure that nothing uses it.
The policy is to never break things that users rely on, so you should
only disable the system calls if you control all of user space and want
to ensure that whatever works now doesn't break in the future.

> > The "#ifdef __NR_clock_settime" is always true when __TIMESIZE != 64,
> > so that could be simplified to the version I suggested.
>
> For following setup: WORDSIZE=32, TIMESIZE=32 and kernel with
> __NR_clock_settime returning -ENOSYS (disabled by embedded system
> designer in the kernel), but supporting __NR_clock_settime64 (for
> example 32 bit ARM):
>
> The policy question - shall the user space binary after calling
> clock_settime:
>
> 1. Receive -ENOSYS as the __NR_clock_settime was used to fulfill the
> request
>
> or
>
> 2. Receive 0 (operation succeed) as the available __NR_clock_settime64
> has been used to perform the requested operation.
>
>
> For the proposed patch (clock_settime) - the option 2 is now performed.

I would prefer to fail as early as possible, maybe even a failure from the
ld.so when loading a binary that links against clock_settime() on a kernel that
doesn't have the system call. That's probably too hard to implement,
so abort(), or return -ENOSYS.

Definitely don't return success, that would defeat the purpose of
disabling the syscall in the kernel, and just lead to silent incorrect
data.

> > > However, there is the problem that in some point in time the glibc
> > > will switch to 64 bit __TIMESIZE only (probably when minimal kernel
> > > version for glibc would be grater than 5.1) and all __clock_settime
> > > syscalls would be served with __clock_settime64 (as 64 bit time
> > > support is always in place).
> > >
> > > After this switch the "unconverted" program will setup wrong time.
> >
> > I don't understand. What does it mean to switch to __TIMESIZE=64?
> > Would that not break all existing binaries regardless of the
> > implementation?
>
> __TIMESIZE represents the size of time_t (the glibc internal time
> representation). This change would be probably performed in the future
> after the _TIME_BITS==64 is defined by default.

I'm still not following. Which of steps listed below would that correspond
to? I guess the last one, right?

> > Between adding the time64 system calls (now) and removing
> > the time32 system calls (in y2038), there are a couple of
> > intermediate steps that can be years apart, or all happen
> > at the same time:
> >
> > - drop support for building with pre-5.1 kernel headers
> > - stop running on pre-5.1 kernels
> > - change the default for newly compiled code to time64
> > - drop support for building with time32

       Arnd

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 4322 bytes --]

Hi Arnd,

> On Wed, Jun 26, 2019 at 5:03 PM Lukasz Majewski <lukma@denx.de> wrote:
> > > On Wed, Jun 26, 2019 at 11:07 AM Lukasz Majewski <lukma@denx.de>
> > > wrote:  
> > > > > On Tue, Jun 25, 2019 at 5:51 PM Lukasz Majewski
> > > > > <lukma@denx.de>  
> > > >
> > > > Shouldn't those syscalls be kept until the minimal supported
> > > > glibc kernel version is 5.1?  
> > >
> > > We will probably keep them as an option in the kernel until 2038,
> > > but leave it to the distro or embedded system design to turn them
> > > on or off.  
> >
> > Isn't this the ABI break on demand ?  
> 
> It's removing an unused ABI in order to ensure that nothing uses it.
> The policy is to never break things that users rely on, so you should
> only disable the system calls if you control all of user space and
> want to ensure that whatever works now doesn't break in the future.

In other words use glibc to help with validation of the system by
disabling (by kernel option) the time32 syscalls and check what happens?

> 
> > > The "#ifdef __NR_clock_settime" is always true when __TIMESIZE !=
> > > 64, so that could be simplified to the version I suggested.  
> >
> > For following setup: WORDSIZE=32, TIMESIZE=32 and kernel with
> > __NR_clock_settime returning -ENOSYS (disabled by embedded system
> > designer in the kernel), but supporting __NR_clock_settime64 (for
> > example 32 bit ARM):
> >
> > The policy question - shall the user space binary after calling
> > clock_settime:
> >
> > 1. Receive -ENOSYS as the __NR_clock_settime was used to fulfill the
> > request
> >
> > or
> >
> > 2. Receive 0 (operation succeed) as the available
> > __NR_clock_settime64 has been used to perform the requested
> > operation.
> >
> >
> > For the proposed patch (clock_settime) - the option 2 is now
> > performed.  
> 
> I would prefer to fail as early as possible, maybe even a failure
> from the ld.so when loading a binary that links against
> clock_settime() on a kernel that doesn't have the system call. That's
> probably too hard to implement, so abort(), or return -ENOSYS.

I see your point. Let's wait for other glibc developers opinion.

> 
> Definitely don't return success, that would defeat the purpose of
> disabling the syscall in the kernel, and just lead to silent incorrect
> data.
> 
> > > > However, there is the problem that in some point in time the
> > > > glibc will switch to 64 bit __TIMESIZE only (probably when
> > > > minimal kernel version for glibc would be grater than 5.1) and
> > > > all __clock_settime syscalls would be served with
> > > > __clock_settime64 (as 64 bit time support is always in place).
> > > >
> > > > After this switch the "unconverted" program will setup wrong
> > > > time.  
> > >
> > > I don't understand. What does it mean to switch to __TIMESIZE=64?
> > > Would that not break all existing binaries regardless of the
> > > implementation?  
> >
> > __TIMESIZE represents the size of time_t (the glibc internal time
> > representation). This change would be probably performed in the
> > future after the _TIME_BITS==64 is defined by default.  
> 
> I'm still not following. Which of steps listed below would that
> correspond to? I guess the last one, right?
> 
> > > Between adding the time64 system calls (now) and removing
> > > the time32 system calls (in y2038), there are a couple of
> > > intermediate steps that can be years apart, or all happen
> > > at the same time:
> > >
> > > - drop support for building with pre-5.1 kernel headers
> > > - stop running on pre-5.1 kernels
        ^^^ __ASSUME_TIME32_SYSCALLS flag which will be always true then

> > > - change the default for newly compiled code to time64
        ^^^ The _TIME_BITS==64 set by default (in glibc) for all
        compiled programs


> > > - drop support for building with time32  
        ^^^ TIMESIZE == 64 (no support for time32)

(But this need ACK from e.g. Joseph if I understood it correctly).

> 
>        Arnd




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Arnd Bergmann]

On Thu, Jun 27, 2019 at 12:55 AM Lukasz Majewski <lukma@denx.de> wrote:
> > On Wed, Jun 26, 2019 at 5:03 PM Lukasz Majewski <lukma@denx.de> wrote:
> > > > On Wed, Jun 26, 2019 at 11:07 AM Lukasz Majewski <lukma@denx.de>
> > > > wrote:
> > > > > > On Tue, Jun 25, 2019 at 5:51 PM Lukasz Majewski
> > > > > > <lukma@denx.de>
> > > > >
> > > > > Shouldn't those syscalls be kept until the minimal supported
> > > > > glibc kernel version is 5.1?
> > > >
> > > > We will probably keep them as an option in the kernel until 2038,
> > > > but leave it to the distro or embedded system design to turn them
> > > > on or off.
> > >
> > > Isn't this the ABI break on demand ?
> >
> > It's removing an unused ABI in order to ensure that nothing uses it.
> > The policy is to never break things that users rely on, so you should
> > only disable the system calls if you control all of user space and
> > want to ensure that whatever works now doesn't break in the future.
>
> In other words use glibc to help with validation of the system by
> disabling (by kernel option) the time32 syscalls and check what happens?

Yes. [ Even better would be a compile-time option to just leave out
the time32 support from glibc entirely, but as I understand that will
not be possible until most users have moved over to time64,
and users can't wait for that to do validation on products shipping now. ]

Mostly this means to just not put in code to support a case that
nobody cares about (running time32 applications on pure time64
systems), so I would not expect this to cause extra effort in development,
just a little care with the implementation.


> > > > However, there is the problem that in some point in time the
> > > > glibc will switch to 64 bit __TIMESIZE only (probably when
> > > > minimal kernel version for glibc would be grater than 5.1) and
> > > > all __clock_settime syscalls would be served with
> > > > __clock_settime64 (as 64 bit time support is always in place).
> > > >
> > > > After this switch the "unconverted" program will setup wrong
> > > > time.
>
> I'm still not following. Which of steps listed below would that
> correspond to? I guess the last one, right?
>
> > > > - drop support for building with time32
>         ^^^ TIMESIZE == 64 (no support for time32)
>
> (But this need ACK from e.g. Joseph if I understood it correctly).

I still don't see how that would break anything: if applications
are all built with 64-bit time_t, they would not call into the old
__clock_settime() function, which is then only kept around
for compatibility with old binaries and would still operate on
32-bit time_t and use __NR_clock_settime.

      Arnd

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 3697 bytes --]

Hi Arnd

> On Thu, Jun 27, 2019 at 12:55 AM Lukasz Majewski <lukma@denx.de>
> wrote:
> > > On Wed, Jun 26, 2019 at 5:03 PM Lukasz Majewski <lukma@denx.de>
> > > wrote:  
> > > > > On Wed, Jun 26, 2019 at 11:07 AM Lukasz Majewski
> > > > > <lukma@denx.de> wrote:  
> > > > > > > On Tue, Jun 25, 2019 at 5:51 PM Lukasz Majewski
> > > > > > > <lukma@denx.de>  
> > > > > >
> > > > > > Shouldn't those syscalls be kept until the minimal supported
> > > > > > glibc kernel version is 5.1?  
> > > > >
> > > > > We will probably keep them as an option in the kernel until
> > > > > 2038, but leave it to the distro or embedded system design to
> > > > > turn them on or off.  
> > > >
> > > > Isn't this the ABI break on demand ?  
> > >
> > > It's removing an unused ABI in order to ensure that nothing uses
> > > it. The policy is to never break things that users rely on, so
> > > you should only disable the system calls if you control all of
> > > user space and want to ensure that whatever works now doesn't
> > > break in the future.  
> >
> > In other words use glibc to help with validation of the system by
> > disabling (by kernel option) the time32 syscalls and check what
> > happens?  
> 
> Yes. [ Even better would be a compile-time option to just leave out
> the time32 support from glibc entirely, but as I understand that will
> not be possible until most users have moved over to time64,
> and users can't wait for that to do validation on products shipping
> now. ]
> 
> Mostly this means to just not put in code to support a case that
> nobody cares about (running time32 applications on pure time64
> systems), so I would not expect this to cause extra effort in
> development, just a little care with the implementation.
> 
> 
> > > > > However, there is the problem that in some point in time the
> > > > > glibc will switch to 64 bit __TIMESIZE only (probably when
> > > > > minimal kernel version for glibc would be grater than 5.1) and
> > > > > all __clock_settime syscalls would be served with
> > > > > __clock_settime64 (as 64 bit time support is always in place).
> > > > >
> > > > > After this switch the "unconverted" program will setup wrong
> > > > > time.  
> >
> > I'm still not following. Which of steps listed below would that
> > correspond to? I guess the last one, right?
> >  
> > > > > - drop support for building with time32  
> >         ^^^ TIMESIZE == 64 (no support for time32)
> >
> > (But this need ACK from e.g. Joseph if I understood it correctly).  
> 
> I still don't see how that would break anything: if applications
> are all built with 64-bit time_t, they would not call into the old
> __clock_settime() function, which is then only kept around
> for compatibility with old binaries and would still operate on
> 32-bit time_t and use __NR_clock_settime.
> 
>       Arnd

After the discussion I do believe that it would be correct to change
the proposed patch [1] '__clock_settime' to:

#if __TIMESIZE != 64
int
__clock_settime (clockid_t clock_id, const struct timespec *tp)
{
/* For archs with WORDSIZE==32, which do not support clock_settime64
the clock_settime supporting 32 bit time ABI will be used */

return INLINE_SYSCALL_CALL (clock_settime, clock_id, tp);
}
#endif  


The "__clock_settime64()" part could be left untouched.


Note:

[1] - https://patchwork.ozlabs.org/patch/1107235/

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Arnd Bergmann]

On Thu, Jun 27, 2019 at 12:36 PM Lukasz Majewski <lukma@denx.de> wrote:
> > On Thu, Jun 27, 2019 at 12:55 AM Lukasz Majewski <lukma@denx.de>

> After the discussion I do believe that it would be correct to change
> the proposed patch [1] '__clock_settime' to:
>
> #if __TIMESIZE != 64

This would hide the function on 64-bit architectures, right?

Maybe
#if (__TIMESIZE == __WORDSIZE) || (defined __x86_64__ && defined __ILP32__)

or shortening that by adding a new macro

#if __ASSUME_TIME32_SYSCALLS

> int
> __clock_settime (clockid_t clock_id, const struct timespec *tp)
> {
> /* For archs with WORDSIZE==32, which do not support clock_settime64
> the clock_settime supporting 32 bit time ABI will be used */

Same for the comment: __clock_settime would be used both
on 64-bit architectures as the normal path, and for compatiblity
with applications built without _TIME_BITS=64.

> return INLINE_SYSCALL_CALL (clock_settime, clock_id, tp);
> }
> #endif
>
> The "__clock_settime64()" part could be left untouched.

Ok.

      Arnd

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 3772 bytes --]

Hi Arnd,

> On Thu, Jun 27, 2019 at 12:36 PM Lukasz Majewski <lukma@denx.de>
> wrote:
> > > On Thu, Jun 27, 2019 at 12:55 AM Lukasz Majewski <lukma@denx.de>  
> 
> > After the discussion I do believe that it would be correct to change
> > the proposed patch [1] '__clock_settime' to:
> >
> > #if __TIMESIZE != 64  
> 
> This would hide the function on 64-bit architectures, right?

Yes, this function would be hidden on architectures with __WORDSIZE==64
(e.g. x86_64) (+ x32 ).

> 
> Maybe
> #if (__TIMESIZE == __WORDSIZE) || (defined __x86_64__ && defined
> __ILP32__)
> 
> or shortening that by adding a new macro
> 
> #if __ASSUME_TIME32_SYSCALLS

Please see below comment.

> 
> > int
> > __clock_settime (clockid_t clock_id, const struct timespec *tp)
> > {
> > /* For archs with WORDSIZE==32, which do not support clock_settime64
> > the clock_settime supporting 32 bit time ABI will be used */  
> 
> Same for the comment: __clock_settime would be used both
> on 64-bit architectures as the normal path, and for compatiblity
> with applications built without _TIME_BITS=64.

With the patch [1] - it would be used in such a way:

1. For archs with WORDSIZE==32 and __TIMESIZE==32 (legacy ones - e.g.
arm 32 bits)

#if __TIMESIZE != 64
int
__clock_settime (clockid_t clock_id, const struct timespec *tp)
{
	return clock_settime(....)
}
#endif


2. For arch with WORDSIZE==64 (and WORDSIZE_SYSCALL=64 -> x32) and
__TIMESIZE==64

__clock_settime64 (clockid_t clock_id, const struct __timespec64 *tp)
{
#ifdef __ASSUME_TIME64_SYSCALLS
# ifndef __NR_clock_settime64
#  define __NR_clock_settime64 __NR_clock_settime
# endif
  return INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
#else
....


}

The __ASSUME_TIME64_SYSCALLS is always defined in this case [2]

Here the assumption is that for such architectures (like aarch64 or
x86_64) the __NR_clock_settime64 (if ever introduced) has the same ABI
as __NR_clock_settime, so there will be no need to adjust the glibc code.


3. New archs added or ones being Y2038 safe (with __NR_clock_settime64
available in the kernel -> starting from 5.1+).

For them the __ASSUME_TIME64_SYSCALLS is defined [2] and execution
patch from point 2. is used with potential fallback to 32 bit version
of clock_settime:

__clock_settime64 (clockid_t clock_id, const struct __timespec64 *tp)
{
#ifdef __ASSUME_TIME64_SYSCALLS
# ifndef __NR_clock_settime64
#  define __NR_clock_settime64 __NR_clock_settime
# endif
  return INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
#else
# ifdef __NR_clock_settime64
  int ret = INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
  if (ret == 0 || errno != ENOSYS)
    return ret;
# endif
  if (! in_time_t_range (tp->tv_sec))
    {
      __set_errno (EOVERFLOW);
      return -1;
    }

  struct timespec ts32;
  valid_timespec64_to_timespec (tp, &ts32);
  return INLINE_SYSCALL_CALL (clock_settime, clock_id, &ts32);
#endif
}

Note for the above code:

The __NR_clock_settime64 is used whenever possible and if not available
the fallback to 32 bit time supporting clock_settime is executed (with
overflow check).


> 
> > return INLINE_SYSCALL_CALL (clock_settime, clock_id, tp);
> > }
> > #endif
> >
> > The "__clock_settime64()" part could be left untouched.  
> 
> Ok.
> 
>       Arnd

Note:

[1] - https://patchwork.ozlabs.org/patch/1107235/
[2] - https://patchwork.ozlabs.org/patch/1117100/


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Arnd Bergmann]

On Thu, Jun 27, 2019 at 4:08 PM Lukasz Majewski <lukma@denx.de> wrote:
> > On Thu, Jun 27, 2019 at 12:36 PM Lukasz Majewski <lukma@denx.de> wrote:
> 2. For arch with WORDSIZE==64 (and WORDSIZE_SYSCALL=64 -> x32) and
> __TIMESIZE==64
>
> __clock_settime64 (clockid_t clock_id, const struct __timespec64 *tp)
> {
> #ifdef __ASSUME_TIME64_SYSCALLS
> # ifndef __NR_clock_settime64
> #  define __NR_clock_settime64 __NR_clock_settime
> # endif
>   return INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
> #else
> ....

Ok, I see. I missed the fact that you also had
__ASSUME_TIME64_SYSCALLS on 64-bit architectures,
and define a local __NR_clock_settime64, and just
assumed that the 64-bit case would be unmodified from what
it is now.

Are you missing a

weak_alias (__clock_settime64, clock_settime)

in this case?

   Arnd

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 2102 bytes --]

Hi Arnd,

> On Thu, Jun 27, 2019 at 4:08 PM Lukasz Majewski <lukma@denx.de> wrote:
> > > On Thu, Jun 27, 2019 at 12:36 PM Lukasz Majewski <lukma@denx.de>
> > > wrote:  
> > 2. For arch with WORDSIZE==64 (and WORDSIZE_SYSCALL=64 -> x32) and
> > __TIMESIZE==64
> >
> > __clock_settime64 (clockid_t clock_id, const struct __timespec64
> > *tp) {
> > #ifdef __ASSUME_TIME64_SYSCALLS
> > # ifndef __NR_clock_settime64
> > #  define __NR_clock_settime64 __NR_clock_settime
> > # endif
> >   return INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
> > #else
> > ....  
> 
> Ok, I see. I missed the fact that you also had
> __ASSUME_TIME64_SYSCALLS on 64-bit architectures,
> and define a local __NR_clock_settime64, and just
> assumed that the 64-bit case would be unmodified from what
> it is now.

Yes. Exactly.

> 
> Are you missing a
> 
> weak_alias (__clock_settime64, clock_settime)
> 
> in this case?

I think that it is not necessary as the patch [1] has following code:

> 
>    Arnd

 
#if __TIMESIZE == 64
# define __clock_settime64 __clock_settime
#else
extern int __clock_settime64 (clockid_t clock_id,
                              const struct __timespec64 *tp);
libc_hidden_proto (__clock_settime64)
#endif

So for archs supporting 64 bit time syscalls (WORDSIZE==64 &&
WORDSIZE_SYSCALLS==64) we have the #define and the
weak_alias (__clock_settime, clock_settime) does the job.



If you are interested, please look into patch [2], which is a
proposition of using clock_settime as a part of Y2038 safe system.
This code corresponds to v3 of adding clock_settime syscall support,
which is a bit outdated as now we discuss v5. It gives a rough idea
though.


Note:

[1] - https://patchwork.ozlabs.org/patch/1107235/
[2] - https://patchwork.ozlabs.org/patch/1096352/

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Arnd Bergmann]

On Thu, Jun 27, 2019 at 5:23 PM Lukasz Majewski <lukma@denx.de> wrote:

>
> I think that it is not necessary as the patch [1] has following code:

> #if __TIMESIZE == 64
> # define __clock_settime64 __clock_settime
> #else
> extern int __clock_settime64 (clockid_t clock_id,
>                               const struct __timespec64 *tp);
> libc_hidden_proto (__clock_settime64)
> #endif
>
> So for archs supporting 64 bit time syscalls (WORDSIZE==64 &&
> WORDSIZE_SYSCALLS==64) we have the #define and the
> weak_alias (__clock_settime, clock_settime) does the job.

Ok, so you redirect both __clock_settime64 to __clock_settime
and __NR_settime64 to __NR_settime, in order to get back to the
same definition that you have today on 64-bit.

Sorry for taking so long to understand that.

> If you are interested, please look into patch [2], which is a
> proposition of using clock_settime as a part of Y2038 safe system.
> This code corresponds to v3 of adding clock_settime syscall support,
> which is a bit outdated as now we discuss v5. It gives a rough idea
> though.

Yes, that part looked fine to me from the beginning.

      Arnd

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

Hi Arnd,

> On Thu, Jun 27, 2019 at 5:23 PM Lukasz Majewski <lukma@denx.de> wrote:
> 
> >
> > I think that it is not necessary as the patch [1] has following
> > code:  
> 
> > #if __TIMESIZE == 64
> > # define __clock_settime64 __clock_settime
> > #else
> > extern int __clock_settime64 (clockid_t clock_id,
> >                               const struct __timespec64 *tp);
> > libc_hidden_proto (__clock_settime64)
> > #endif
> >
> > So for archs supporting 64 bit time syscalls (WORDSIZE==64 &&
> > WORDSIZE_SYSCALLS==64) we have the #define and the
> > weak_alias (__clock_settime, clock_settime) does the job.  
> 
> Ok, so you redirect both __clock_settime64 to __clock_settime
> and __NR_settime64 to __NR_settime, in order to get back to the
> same definition that you have today on 64-bit.
> 
> Sorry for taking so long to understand that.

Not only you had a hard time to understand it.

The approach presented in this patch steams from following guidelines:

https://www.gnu.org/software/libc/manual/html_mono/libc.html
"D.2.1 64-bit time symbol handling in the GNU C Library"


> 
> > If you are interested, please look into patch [2], which is a
> > proposition of using clock_settime as a part of Y2038 safe system.
> > This code corresponds to v3 of adding clock_settime syscall support,
> > which is a bit outdated as now we discuss v5. It gives a rough idea
> > though.  
> 
> Yes, that part looked fine to me from the beginning.

Ok. Good :-)

> 
>       Arnd




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Arnd Bergmann]

On Thu, Jun 27, 2019 at 6:17 PM Lukasz Majewski <lukma@denx.de> wrote:

> >
> > Ok, so you redirect both __clock_settime64 to __clock_settime
> > and __NR_settime64 to __NR_settime, in order to get back to the
> > same definition that you have today on 64-bit.
> >
> > Sorry for taking so long to understand that.
>
> Not only you had a hard time to understand it.

Here is how I had imagined it would be done in a way that I find
easier to understand:

#if __WORDSIZE == 32 /* yes, all of them including rv32 and x32 */
__clock_settime64 (clockid_t clock_id, const struct __timespec64 *tp)
{
   int ret;

   /* Make sure the time cvalue is OK.  */
   if (tp->tv_nsec < 0 || tp->tv_nsec >= 1000000000)
    {
       __set_errno (EINVAL);
       return -1;
     }
#ifdef __NR_clock_settime64
 ret = INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
#endif

#ifndef __ASSUME_TIME64_SYSCALLS
  if (ret == 0 || errno != ENOSYS)
    return ret;

  if (! in_time_t_range (tp->tv_sec))
    {
      __set_errno (EOVERFLOW);
      return -1;
    }

  struct timespec ts32;
  valid_timespec64_to_timespec (tp, &ts32);
  ret = INLINE_SYSCALL_CALL (clock_settime, clock_id, &ts32);
#endif

  return ret;
}
#endif

This should be functionally identical to what you have, but avoid
some of the complexity, especially once linux-5.1 becomes the
minimum version.

      Arnd

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 2533 bytes --]

Hi Arnd,

> On Thu, Jun 27, 2019 at 6:17 PM Lukasz Majewski <lukma@denx.de> wrote:
> 
> > >
> > > Ok, so you redirect both __clock_settime64 to __clock_settime
> > > and __NR_settime64 to __NR_settime, in order to get back to the
> > > same definition that you have today on 64-bit.
> > >
> > > Sorry for taking so long to understand that.  
> >
> > Not only you had a hard time to understand it.  
> 
> Here is how I had imagined it would be done in a way that I find
> easier to understand:
> 
> #if __WORDSIZE == 32 /* yes, all of them including rv32 and x32 */
> __clock_settime64 (clockid_t clock_id, const struct __timespec64 *tp)
> {
>    int ret;
> 
>    /* Make sure the time cvalue is OK.  */
>    if (tp->tv_nsec < 0 || tp->tv_nsec >= 1000000000)
>     {
>        __set_errno (EINVAL);
>        return -1;
>      }
> #ifdef __NR_clock_settime64
>  ret = INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
> #endif
> 
> #ifndef __ASSUME_TIME64_SYSCALLS
>   if (ret == 0 || errno != ENOSYS)
>     return ret;
> 
>   if (! in_time_t_range (tp->tv_sec))
>     {
>       __set_errno (EOVERFLOW);
>       return -1;
>     }
> 
>   struct timespec ts32;
>   valid_timespec64_to_timespec (tp, &ts32);
>   ret = INLINE_SYSCALL_CALL (clock_settime, clock_id, &ts32);
> #endif
> 
>   return ret;
> }
> #endif
> 
> This should be functionally identical to what you have, but avoid
> some of the complexity, especially once linux-5.1 becomes the
> minimum version.

The semantics for __ASSUME_TIME64_SYSCALLS is under the discussion for
some time [1].

Also the __clock_settime64() implementation from [2] takes into
account some corner cases (like support for all archs since 3.2
kernel, x32, legacy systems, etc). The implementation from [2] IMHO
seems to be more concise and fits into the 64 bit conversion paradigm
for glibc [3].

However, this is only my opinion and we shall wait for other community
members to express their opinions.

> 
>       Arnd


Note:

[1] - https://patchwork.ozlabs.org/patch/1117100/
[2] - https://patchwork.ozlabs.org/patch/1107235/
[3] - 
https://www.gnu.org/software/libc/manual/html_mono/libc.html
"D.2.1 64-bit time symbol handling in the GNU C Library"



Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Alistair Francis]

On Thu, Jun 27, 2019 at 3:08 PM Lukasz Majewski <lukma@denx.de> wrote:
>
> Hi Arnd,
>
> > On Thu, Jun 27, 2019 at 6:17 PM Lukasz Majewski <lukma@denx.de> wrote:
> >
> > > >
> > > > Ok, so you redirect both __clock_settime64 to __clock_settime
> > > > and __NR_settime64 to __NR_settime, in order to get back to the
> > > > same definition that you have today on 64-bit.
> > > >
> > > > Sorry for taking so long to understand that.
> > >
> > > Not only you had a hard time to understand it.
> >
> > Here is how I had imagined it would be done in a way that I find
> > easier to understand:
> >
> > #if __WORDSIZE == 32 /* yes, all of them including rv32 and x32 */
> > __clock_settime64 (clockid_t clock_id, const struct __timespec64 *tp)
> > {
> >    int ret;
> >
> >    /* Make sure the time cvalue is OK.  */
> >    if (tp->tv_nsec < 0 || tp->tv_nsec >= 1000000000)
> >     {
> >        __set_errno (EINVAL);
> >        return -1;
> >      }
> > #ifdef __NR_clock_settime64
> >  ret = INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
> > #endif
> >
> > #ifndef __ASSUME_TIME64_SYSCALLS
> >   if (ret == 0 || errno != ENOSYS)
> >     return ret;
> >
> >   if (! in_time_t_range (tp->tv_sec))
> >     {
> >       __set_errno (EOVERFLOW);
> >       return -1;
> >     }
> >
> >   struct timespec ts32;
> >   valid_timespec64_to_timespec (tp, &ts32);
> >   ret = INLINE_SYSCALL_CALL (clock_settime, clock_id, &ts32);
> > #endif
> >
> >   return ret;
> > }
> > #endif
> >
> > This should be functionally identical to what you have, but avoid
> > some of the complexity, especially once linux-5.1 becomes the
> > minimum version.

This implementation looks good to me. It shouldn't be too hard to
extend this to all the problematic y2038 syscalls.

>
> The semantics for __ASSUME_TIME64_SYSCALLS is under the discussion for
> some time [1].

I don't see any comments on this, do you know the status?

>
> Also the __clock_settime64() implementation from [2] takes into
> account some corner cases (like support for all archs since 3.2
> kernel, x32, legacy systems, etc). The implementation from [2] IMHO
> seems to be more concise and fits into the 64 bit conversion paradigm
> for glibc [3].

This one also works for RV32 :)

Alistair

>
> However, this is only my opinion and we shall wait for other community
> members to express their opinions.
>
> >
> >       Arnd
>
>
> Note:
>
> [1] - https://patchwork.ozlabs.org/patch/1117100/
> [2] - https://patchwork.ozlabs.org/patch/1107235/
> [3] -
> https://www.gnu.org/software/libc/manual/html_mono/libc.html
> "D.2.1 64-bit time symbol handling in the GNU C Library"
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 3893 bytes --]

Hi Alistair,

> On Thu, Jun 27, 2019 at 3:08 PM Lukasz Majewski <lukma@denx.de> wrote:
> >
> > Hi Arnd,
> >  
> > > On Thu, Jun 27, 2019 at 6:17 PM Lukasz Majewski <lukma@denx.de>
> > > wrote: 
> > > > >
> > > > > Ok, so you redirect both __clock_settime64 to __clock_settime
> > > > > and __NR_settime64 to __NR_settime, in order to get back to
> > > > > the same definition that you have today on 64-bit.
> > > > >
> > > > > Sorry for taking so long to understand that.  
> > > >
> > > > Not only you had a hard time to understand it.  
> > >
> > > Here is how I had imagined it would be done in a way that I find
> > > easier to understand:
> > >
> > > #if __WORDSIZE == 32 /* yes, all of them including rv32 and x32 */
> > > __clock_settime64 (clockid_t clock_id, const struct __timespec64
> > > *tp) {
> > >    int ret;
> > >
> > >    /* Make sure the time cvalue is OK.  */
> > >    if (tp->tv_nsec < 0 || tp->tv_nsec >= 1000000000)
> > >     {
> > >        __set_errno (EINVAL);
> > >        return -1;
> > >      }
> > > #ifdef __NR_clock_settime64
> > >  ret = INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
> > > #endif
> > >
> > > #ifndef __ASSUME_TIME64_SYSCALLS
> > >   if (ret == 0 || errno != ENOSYS)
> > >     return ret;
> > >
> > >   if (! in_time_t_range (tp->tv_sec))
> > >     {
> > >       __set_errno (EOVERFLOW);
> > >       return -1;
> > >     }
> > >
> > >   struct timespec ts32;
> > >   valid_timespec64_to_timespec (tp, &ts32);
> > >   ret = INLINE_SYSCALL_CALL (clock_settime, clock_id, &ts32);
> > > #endif
> > >
> > >   return ret;
> > > }
> > > #endif
> > >
> > > This should be functionally identical to what you have, but avoid
> > > some of the complexity, especially once linux-5.1 becomes the
> > > minimum version.  
> 
> This implementation looks good to me. It shouldn't be too hard to
> extend this to all the problematic y2038 syscalls.

This is the plan. After we agree on __ASSUME_TIME64_SYSCALLS semantics
(the other patch - I've add you to CC on the ping for it) it shall be
possible to follow a similar pattern as for __clock_settime for other
syscalls.

> 
> >
> > The semantics for __ASSUME_TIME64_SYSCALLS is under the discussion
> > for some time [1].  
> 
> I don't see any comments on this, do you know the status?

I'm waiting for Joseph's (and the community) review and final
acceptance (pulling to main tree). 

> 
> >
> > Also the __clock_settime64() implementation from [2] takes into
> > account some corner cases (like support for all archs since 3.2
> > kernel, x32, legacy systems, etc). The implementation from [2] IMHO
> > seems to be more concise and fits into the 64 bit conversion
> > paradigm for glibc [3].  
> 
> This one also works for RV32 :)

Good :-). Nice to have some users and testers :-).

> 
> Alistair
> 
> >
> > However, this is only my opinion and we shall wait for other
> > community members to express their opinions.
> >  
> > >
> > >       Arnd  
> >
> >
> > Note:
> >
> > [1] - https://patchwork.ozlabs.org/patch/1117100/
> > [2] - https://patchwork.ozlabs.org/patch/1107235/
> > [3] -
> > https://www.gnu.org/software/libc/manual/html_mono/libc.html
> > "D.2.1 64-bit time symbol handling in the GNU C Library"
> >
> >
> >
> > Best regards,
> >
> > Lukasz Majewski
> >
> > --
> >
> > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > lukma@denx.de  




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 4692 bytes --]

Hi,

> Hi Alistair,
> 
> > On Thu, Jun 27, 2019 at 3:08 PM Lukasz Majewski <lukma@denx.de>
> > wrote:  
> > >
> > > Hi Arnd,
> > >    
> > > > On Thu, Jun 27, 2019 at 6:17 PM Lukasz Majewski <lukma@denx.de>
> > > > wrote:   
> > > > > >
> > > > > > Ok, so you redirect both __clock_settime64 to
> > > > > > __clock_settime and __NR_settime64 to __NR_settime, in
> > > > > > order to get back to the same definition that you have
> > > > > > today on 64-bit.
> > > > > >
> > > > > > Sorry for taking so long to understand that.    
> > > > >
> > > > > Not only you had a hard time to understand it.    
> > > >
> > > > Here is how I had imagined it would be done in a way that I find
> > > > easier to understand:
> > > >
> > > > #if __WORDSIZE == 32 /* yes, all of them including rv32 and x32
> > > > */ __clock_settime64 (clockid_t clock_id, const struct
> > > > __timespec64 *tp) {
> > > >    int ret;
> > > >
> > > >    /* Make sure the time cvalue is OK.  */
> > > >    if (tp->tv_nsec < 0 || tp->tv_nsec >= 1000000000)
> > > >     {
> > > >        __set_errno (EINVAL);
> > > >        return -1;
> > > >      }
> > > > #ifdef __NR_clock_settime64
> > > >  ret = INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
> > > > #endif
> > > >
> > > > #ifndef __ASSUME_TIME64_SYSCALLS
> > > >   if (ret == 0 || errno != ENOSYS)
> > > >     return ret;
> > > >
> > > >   if (! in_time_t_range (tp->tv_sec))
> > > >     {
> > > >       __set_errno (EOVERFLOW);
> > > >       return -1;
> > > >     }
> > > >
> > > >   struct timespec ts32;
> > > >   valid_timespec64_to_timespec (tp, &ts32);
> > > >   ret = INLINE_SYSCALL_CALL (clock_settime, clock_id, &ts32);
> > > > #endif
> > > >
> > > >   return ret;
> > > > }
> > > > #endif
> > > >
> > > > This should be functionally identical to what you have, but
> > > > avoid some of the complexity, especially once linux-5.1 becomes
> > > > the minimum version.    
> > 
> > This implementation looks good to me. It shouldn't be too hard to
> > extend this to all the problematic y2038 syscalls.  
> 
> This is the plan. After we agree on __ASSUME_TIME64_SYSCALLS semantics
> (the other patch - I've add you to CC on the ping for it) it shall be
> possible to follow a similar pattern as for __clock_settime for other
> syscalls.

The exact list of syscalls which should be eligible for similar to
__clock_settime conversion can be found here:

https://patchwork.ozlabs.org/patch/1117100/

(In the patch comment to be precise).

> 
> >   
> > >
> > > The semantics for __ASSUME_TIME64_SYSCALLS is under the discussion
> > > for some time [1].    
> > 
> > I don't see any comments on this, do you know the status?  
> 
> I'm waiting for Joseph's (and the community) review and final
> acceptance (pulling to main tree). 
> 
> >   
> > >
> > > Also the __clock_settime64() implementation from [2] takes into
> > > account some corner cases (like support for all archs since 3.2
> > > kernel, x32, legacy systems, etc). The implementation from [2]
> > > IMHO seems to be more concise and fits into the 64 bit conversion
> > > paradigm for glibc [3].    
> > 
> > This one also works for RV32 :)  
> 
> Good :-). Nice to have some users and testers :-).
> 
> > 
> > Alistair
> >   
> > >
> > > However, this is only my opinion and we shall wait for other
> > > community members to express their opinions.
> > >    
> > > >
> > > >       Arnd    
> > >
> > >
> > > Note:
> > >
> > > [1] - https://patchwork.ozlabs.org/patch/1117100/
> > > [2] - https://patchwork.ozlabs.org/patch/1107235/
> > > [3] -
> > > https://www.gnu.org/software/libc/manual/html_mono/libc.html
> > > "D.2.1 64-bit time symbol handling in the GNU C Library"
> > >
> > >
> > >
> > > Best regards,
> > >
> > > Lukasz Majewski
> > >
> > > --
> > >
> > > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > > lukma@denx.de    
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lukma@denx.de




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Alistair Francis]

On Thu, Jun 27, 2019 at 7:08 AM Lukasz Majewski <lukma@denx.de> wrote:
>
> Hi Arnd,
>
> > On Thu, Jun 27, 2019 at 12:36 PM Lukasz Majewski <lukma@denx.de>
> > wrote:
> > > > On Thu, Jun 27, 2019 at 12:55 AM Lukasz Majewski <lukma@denx.de>
> >
> > > After the discussion I do believe that it would be correct to change
> > > the proposed patch [1] '__clock_settime' to:
> > >
> > > #if __TIMESIZE != 64
> >
> > This would hide the function on 64-bit architectures, right?
>
> Yes, this function would be hidden on architectures with __WORDSIZE==64
> (e.g. x86_64) (+ x32 ).
>
> >
> > Maybe
> > #if (__TIMESIZE == __WORDSIZE) || (defined __x86_64__ && defined
> > __ILP32__)
> >
> > or shortening that by adding a new macro
> >
> > #if __ASSUME_TIME32_SYSCALLS
>
> Please see below comment.
>
> >
> > > int
> > > __clock_settime (clockid_t clock_id, const struct timespec *tp)
> > > {
> > > /* For archs with WORDSIZE==32, which do not support clock_settime64
> > > the clock_settime supporting 32 bit time ABI will be used */
> >
> > Same for the comment: __clock_settime would be used both
> > on 64-bit architectures as the normal path, and for compatiblity
> > with applications built without _TIME_BITS=64.
>
> With the patch [1] - it would be used in such a way:
>
> 1. For archs with WORDSIZE==32 and __TIMESIZE==32 (legacy ones - e.g.
> arm 32 bits)
>
> #if __TIMESIZE != 64
> int
> __clock_settime (clockid_t clock_id, const struct timespec *tp)
> {
>         return clock_settime(....)
> }
> #endif
>
>
> 2. For arch with WORDSIZE==64 (and WORDSIZE_SYSCALL=64 -> x32) and
> __TIMESIZE==64
>
> __clock_settime64 (clockid_t clock_id, const struct __timespec64 *tp)
> {
> #ifdef __ASSUME_TIME64_SYSCALLS
> # ifndef __NR_clock_settime64
> #  define __NR_clock_settime64 __NR_clock_settime
> # endif
>   return INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
> #else
> ....
>
>
> }
>
> The __ASSUME_TIME64_SYSCALLS is always defined in this case [2]
>
> Here the assumption is that for such architectures (like aarch64 or
> x86_64) the __NR_clock_settime64 (if ever introduced) has the same ABI
> as __NR_clock_settime, so there will be no need to adjust the glibc code.
>
>
> 3. New archs added or ones being Y2038 safe (with __NR_clock_settime64
> available in the kernel -> starting from 5.1+).
>
> For them the __ASSUME_TIME64_SYSCALLS is defined [2] and execution
> patch from point 2. is used with potential fallback to 32 bit version
> of clock_settime:
>
> __clock_settime64 (clockid_t clock_id, const struct __timespec64 *tp)
> {
> #ifdef __ASSUME_TIME64_SYSCALLS
> # ifndef __NR_clock_settime64
> #  define __NR_clock_settime64 __NR_clock_settime
> # endif
>   return INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
> #else
> # ifdef __NR_clock_settime64
>   int ret = INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
>   if (ret == 0 || errno != ENOSYS)
>     return ret;
> # endif
>   if (! in_time_t_range (tp->tv_sec))
>     {
>       __set_errno (EOVERFLOW);
>       return -1;
>     }
>
>   struct timespec ts32;
>   valid_timespec64_to_timespec (tp, &ts32);
>   return INLINE_SYSCALL_CALL (clock_settime, clock_id, &ts32);
> #endif
> }
>
> Note for the above code:
>
> The __NR_clock_settime64 is used whenever possible and if not available
> the fallback to 32 bit time supporting clock_settime is executed (with
> overflow check).

So is this the general approach to use for all y2038 problematic syscalls?


Alistair

>
>
> >
> > > return INLINE_SYSCALL_CALL (clock_settime, clock_id, tp);
> > > }
> > > #endif
> > >
> > > The "__clock_settime64()" part could be left untouched.
> >
> > Ok.
> >
> >       Arnd
>
> Note:
>
> [1] - https://patchwork.ozlabs.org/patch/1107235/
> [2] - https://patchwork.ozlabs.org/patch/1117100/
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 5094 bytes --]

Hi Alistair,

> On Thu, Jun 27, 2019 at 7:08 AM Lukasz Majewski <lukma@denx.de> wrote:
> >
> > Hi Arnd,
> >  
> > > On Thu, Jun 27, 2019 at 12:36 PM Lukasz Majewski <lukma@denx.de>
> > > wrote:  
> > > > > On Thu, Jun 27, 2019 at 12:55 AM Lukasz Majewski
> > > > > <lukma@denx.de>  
> > >  
> > > > After the discussion I do believe that it would be correct to
> > > > change the proposed patch [1] '__clock_settime' to:
> > > >
> > > > #if __TIMESIZE != 64  
> > >
> > > This would hide the function on 64-bit architectures, right?  
> >
> > Yes, this function would be hidden on architectures with
> > __WORDSIZE==64 (e.g. x86_64) (+ x32 ).
> >  
> > >
> > > Maybe
> > > #if (__TIMESIZE == __WORDSIZE) || (defined __x86_64__ && defined
> > > __ILP32__)
> > >
> > > or shortening that by adding a new macro
> > >
> > > #if __ASSUME_TIME32_SYSCALLS  
> >
> > Please see below comment.
> >  
> > >  
> > > > int
> > > > __clock_settime (clockid_t clock_id, const struct timespec *tp)
> > > > {
> > > > /* For archs with WORDSIZE==32, which do not support
> > > > clock_settime64 the clock_settime supporting 32 bit time ABI
> > > > will be used */  
> > >
> > > Same for the comment: __clock_settime would be used both
> > > on 64-bit architectures as the normal path, and for compatiblity
> > > with applications built without _TIME_BITS=64.  
> >
> > With the patch [1] - it would be used in such a way:
> >
> > 1. For archs with WORDSIZE==32 and __TIMESIZE==32 (legacy ones -
> > e.g. arm 32 bits)
> >
> > #if __TIMESIZE != 64
> > int
> > __clock_settime (clockid_t clock_id, const struct timespec *tp)
> > {
> >         return clock_settime(....)
> > }
> > #endif
> >
> >
> > 2. For arch with WORDSIZE==64 (and WORDSIZE_SYSCALL=64 -> x32) and
> > __TIMESIZE==64
> >
> > __clock_settime64 (clockid_t clock_id, const struct __timespec64
> > *tp) {
> > #ifdef __ASSUME_TIME64_SYSCALLS
> > # ifndef __NR_clock_settime64
> > #  define __NR_clock_settime64 __NR_clock_settime
> > # endif
> >   return INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
> > #else
> > ....
> >
> >
> > }
> >
> > The __ASSUME_TIME64_SYSCALLS is always defined in this case [2]
> >
> > Here the assumption is that for such architectures (like aarch64 or
> > x86_64) the __NR_clock_settime64 (if ever introduced) has the same
> > ABI as __NR_clock_settime, so there will be no need to adjust the
> > glibc code.
> >
> >
> > 3. New archs added or ones being Y2038 safe (with
> > __NR_clock_settime64 available in the kernel -> starting from 5.1+).
> >
> > For them the __ASSUME_TIME64_SYSCALLS is defined [2] and execution
> > patch from point 2. is used with potential fallback to 32 bit
> > version of clock_settime:
> >
> > __clock_settime64 (clockid_t clock_id, const struct __timespec64
> > *tp) {
> > #ifdef __ASSUME_TIME64_SYSCALLS
> > # ifndef __NR_clock_settime64
> > #  define __NR_clock_settime64 __NR_clock_settime
> > # endif
> >   return INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
> > #else
> > # ifdef __NR_clock_settime64
> >   int ret = INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
> >   if (ret == 0 || errno != ENOSYS)
> >     return ret;
> > # endif
> >   if (! in_time_t_range (tp->tv_sec))
> >     {
> >       __set_errno (EOVERFLOW);
> >       return -1;
> >     }
> >
> >   struct timespec ts32;
> >   valid_timespec64_to_timespec (tp, &ts32);
> >   return INLINE_SYSCALL_CALL (clock_settime, clock_id, &ts32);
> > #endif
> > }
> >
> > Note for the above code:
> >
> > The __NR_clock_settime64 is used whenever possible and if not
> > available the fallback to 32 bit time supporting clock_settime is
> > executed (with overflow check).  
> 
> So is this the general approach to use for all y2038 problematic
> syscalls?

There is still ongoing discussion regarding the
__ASSUME_TIME64_SYSCALLS flag semantics and the clock_settime
implementation (as an example of syscall conversion).

Until both are pulled upstream - there is still room for changes (and
of course discussion).

> 
> 
> Alistair
> 
> >
> >  
> > >  
> > > > return INLINE_SYSCALL_CALL (clock_settime, clock_id, tp);
> > > > }
> > > > #endif
> > > >
> > > > The "__clock_settime64()" part could be left untouched.  
> > >
> > > Ok.
> > >
> > >       Arnd  
> >
> > Note:
> >
> > [1] - https://patchwork.ozlabs.org/patch/1107235/
> > [2] - https://patchwork.ozlabs.org/patch/1117100/
> >
> >
> > Best regards,
> >
> > Lukasz Majewski
> >
> > --
> >
> > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > lukma@denx.de  




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation

[Joseph Myers]

On Tue, 25 Jun 2019, Arnd Bergmann wrote:

> Your __clock_settime however does the reverse: you have an application
> that calls clock_settime(), the alias redirects that to __clock_settime(),
> and that converts it into the 64-bit structure and passes it into
> __clock_settime64(), which then calls the time64 syscall before falling
> back to calling the time32 syscall.

Yes, that's exactly what it's meant to do.

My position is as stated at 
<https://sourceware.org/ml/libc-alpha/2018-12/msg00136.html>.  Duplicating 
nontrivial functions at the source-code level for 32-bit / 64-bit time is 
unmaintainable; duplicating them at the binary level is unreasonable bloat 
(for avoidance of doubt, this is a sustained objection).  Thus calls to 
pthread_mutex_timedlock for 32-bit time must end up using syscalls with 
64-bit time, because implementation approaches other than thin wrappers 
round the 64-bit version are unreasonable.

I think the appropriate definition of a trivial interface for 32-bit time, 
for which it's OK not to use a thin wrapper, is a syscall wrapper 
generated through syscalls.list; anything requiring actual C code to 
implement the function should be a thin wrapper round the version using 
64-bit time rather than having a variant that just tries to use the 32-bit 
syscall without attempting the 64-bit one.

As I said in <https://sourceware.org/ml/libc-alpha/2018-12/msg00144.html>, 
the choice of syscalls behind a function in glibc has never been a stable 
interface in glibc, and I don't think it ever reasonably can be a stable 
interface; you have to use the dynamic symbol table to identify whether a 
binary is using interfaces for 32-bit time, rather than basing things on 
what syscalls it uses at runtime.

-- 
Joseph S. Myers
joseph@codesourcery.com

[RFC v2 04/20] include/time.h: Fix conflicting timespec types on 32-bit

[Alistair Francis]

On 32-bit systems with 64-bit time_t the timespec variable will be set
to struct __timespec64 which doesn't match the expected function pointer
for __clock_settime64.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
 include/time.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/time.h b/include/time.h
index 7155b2e4db..d62fc7b2c3 100644
--- a/include/time.h
+++ b/include/time.h
@@ -53,7 +53,8 @@ extern void __tz_compute (__time64_t timer, struct tm *tm, int use_localtime)
   __THROW attribute_hidden;
 
 #if __WORDSIZE == 64 \
-  || (defined __SYSCALL_WORDSIZE && __SYSCALL_WORDSIZE == 64)
+  || (defined __SYSCALL_WORDSIZE && __SYSCALL_WORDSIZE == 64) \
+  || __TIMESIZE == 64
 # define __timespec64 timespec
 #else
 /* The glibc Y2038-proof struct __timespec64 structure for a time value.
-- 
2.22.0

Re: [RFC v2 04/20] include/time.h: Fix conflicting timespec types on 32-bit

[Arnd Bergmann]

On Tue, Jun 25, 2019 at 2:11 AM Alistair Francis
<alistair.francis@wdc.com> wrote:

> --- a/include/time.h
> +++ b/include/time.h
> @@ -53,7 +53,8 @@ extern void __tz_compute (__time64_t timer, struct tm *tm, int use_localtime)
>    __THROW attribute_hidden;
>
>  #if __WORDSIZE == 64 \
> -  || (defined __SYSCALL_WORDSIZE && __SYSCALL_WORDSIZE == 64)
> +  || (defined __SYSCALL_WORDSIZE && __SYSCALL_WORDSIZE == 64) \
> +  || __TIMESIZE == 64
>  # define __timespec64 timespec
>  #else
>  /* The glibc Y2038-proof struct __timespec64 structure for a time value.

I think you need a bit more here: on 32-bit architectures with 64-bit time_t,
we require padding in 'struct timespec' next to tv_nsec (before or after,
depending on endianess), and I don't see  a patch in your series that
changes 'timespec' accordingly.

See also https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#struct_timespec

       Arnd

Re: [RFC v2 04/20] include/time.h: Fix conflicting timespec types on 32-bit

[Alistair Francis]

On Tue, Jun 25, 2019 at 4:17 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Jun 25, 2019 at 2:11 AM Alistair Francis
> <alistair.francis@wdc.com> wrote:
>
> > --- a/include/time.h
> > +++ b/include/time.h
> > @@ -53,7 +53,8 @@ extern void __tz_compute (__time64_t timer, struct tm *tm, int use_localtime)
> >    __THROW attribute_hidden;
> >
> >  #if __WORDSIZE == 64 \
> > -  || (defined __SYSCALL_WORDSIZE && __SYSCALL_WORDSIZE == 64)
> > +  || (defined __SYSCALL_WORDSIZE && __SYSCALL_WORDSIZE == 64) \
> > +  || __TIMESIZE == 64
> >  # define __timespec64 timespec
> >  #else
> >  /* The glibc Y2038-proof struct __timespec64 structure for a time value.
>
> I think you need a bit more here: on 32-bit architectures with 64-bit time_t,
> we require padding in 'struct timespec' next to tv_nsec (before or after,
> depending on endianess), and I don't see  a patch in your series that
> changes 'timespec' accordingly.
>
> See also https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#struct_timespec

Good point, I have updated this.

Alistair

>
>        Arnd

[RFC v2 05/20] sysdeps/nanosleep: Use clock_nanosleep_time64 if avaliable

[Alistair Francis]

The nanosleep syscall is not supported on newer 32-bit platforms (such
as RV32). To fix this issue let's use clock_nanosleep_time64 if it is
avaliable.

Let's use CLOCK_REALTIME when calling clock_nanosleep_time64 as the
Linux specification says:
  "POSIX.1 specifies that nanosleep() should measure time against the
   CLOCK_REALTIME clock. However, Linux measures the time using the
   CLOCK_MONOTONIC clock. This probably does not matter, since the POSIX.1
   specification for clock_settime(2) says that discontinuous changes in
   CLOCK_REALTIME should not affect nanosleep()"

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
 ChangeLog                                    |  6 ++++++
 nptl/thrd_sleep.c                            | 19 ++++++++++++++++++-
 sysdeps/unix/sysv/linux/nanosleep.c          | 12 ++++++++++++
 sysdeps/unix/sysv/linux/nanosleep_nocancel.c | 11 +++++++++++
 4 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index 05291d7825..b90c5ab60c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2019-06-21  Alistair Francis  <alistair.francis@wdc.com>
+
+	* nptl/thrd_sleep.c: Use clock_nanosleep_time64 instead of nanosleep.
+	* sysdeps/unix/sysv/linux/nanosleep.c: Likewise.
+	* sysdeps/unix/sysv/linux/nanosleep_nocancel.c: Likewise.
+
 2019-06-20  Dmitry V. Levin  <ldv@altlinux.org>
 	    Florian Weimer  <fweimer@redhat.com>
 
diff --git a/nptl/thrd_sleep.c b/nptl/thrd_sleep.c
index 07a51808df..09f8c7159f 100644
--- a/nptl/thrd_sleep.c
+++ b/nptl/thrd_sleep.c
@@ -25,7 +25,24 @@ int
 thrd_sleep (const struct timespec* time_point, struct timespec* remaining)
 {
   INTERNAL_SYSCALL_DECL (err);
-  int ret = INTERNAL_SYSCALL_CANCEL (nanosleep, err, time_point, remaining);
+  int ret;
+
+#ifdef __ASSUME_TIME64_SYSCALLS
+  ret = INTERNAL_SYSCALL_CANCEL (clock_nanosleep_time64, err,
+                                 CLOCK_REALTIME, 0, time_point, remaining);
+#else
+# ifdef __NR_clock_nanosleep_time64
+  long int ret_64 = INTERNAL_SYSCALL_CANCEL (clock_nanosleep_time64, err,
+                                             CLOCK_REALTIME, 0, time_point, remaining);
+  if (ret_64 == 0 || errno != ENOSYS) {
+    ret = ret_64;
+  } else {
+    ret = INTERNAL_SYSCALL_CANCEL (nanosleep, err, time_point, remaining);
+  }
+# else
+  ret = INTERNAL_SYSCALL_CANCEL (nanosleep, err, time_point, remaining);
+# endif
+#endif
   if (INTERNAL_SYSCALL_ERROR_P (ret, err))
     {
       /* C11 states thrd_sleep function returns -1 if it has been interrupted
diff --git a/sysdeps/unix/sysv/linux/nanosleep.c b/sysdeps/unix/sysv/linux/nanosleep.c
index f14ae565af..c2d6e2f766 100644
--- a/sysdeps/unix/sysv/linux/nanosleep.c
+++ b/sysdeps/unix/sysv/linux/nanosleep.c
@@ -25,7 +25,19 @@ int
 __nanosleep (const struct timespec *requested_time,
 	     struct timespec *remaining)
 {
+
+#ifdef __ASSUME_TIME64_SYSCALLS
+  return SYSCALL_CANCEL (clock_nanosleep_time64, CLOCK_REALTIME, 0,
+                         requested_time, remaining);
+#else
+# ifdef __NR_clock_nanosleep_time64
+  long int ret = SYSCALL_CANCEL (clock_nanosleep_time64, CLOCK_REALTIME, 0,
+                                 requested_time, remaining);
+  if (ret == 0 || errno != ENOSYS)
+    return ret;
+# endif
   return SYSCALL_CANCEL (nanosleep, requested_time, remaining);
+#endif
 }
 hidden_def (__nanosleep)
 weak_alias (__nanosleep, nanosleep)
diff --git a/sysdeps/unix/sysv/linux/nanosleep_nocancel.c b/sysdeps/unix/sysv/linux/nanosleep_nocancel.c
index 122ba627ff..f411a1c6c2 100644
--- a/sysdeps/unix/sysv/linux/nanosleep_nocancel.c
+++ b/sysdeps/unix/sysv/linux/nanosleep_nocancel.c
@@ -24,6 +24,17 @@ int
 __nanosleep_nocancel (const struct timespec *requested_time,
 		      struct timespec *remaining)
 {
+#ifdef __ASSUME_TIME64_SYSCALLS
+  return INLINE_SYSCALL_CALL (clock_nanosleep_time64, CLOCK_REALTIME, 0,
+                         requested_time, remaining);
+#else
+# ifdef __NR_clock_nanosleep_time64
+  long int ret = INLINE_SYSCALL_CALL (clock_nanosleep_time64, CLOCK_REALTIME, 0,
+                                 requested_time, remaining);
+  if (ret == 0 || errno != ENOSYS)
+    return ret;
+# endif
   return INLINE_SYSCALL_CALL (nanosleep, requested_time, remaining);
+#endif
 }
 hidden_def (__nanosleep_nocancel)
-- 
2.22.0

Re: [RFC v2 05/20] sysdeps/nanosleep: Use clock_nanosleep_time64 if avaliable

[Andreas Schwab]

There are quite a few style violations (here and in 08/20): braces on
own line, but no braces for single statements; comment style without
asterisks and no parens after functions; argument continuations to line
up after the paren.

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."

Re: [RFC v2 05/20] sysdeps/nanosleep: Use clock_nanosleep_time64 if avaliable

[Arnd Bergmann]

On Tue, Jun 25, 2019 at 2:11 AM Alistair Francis
<alistair.francis@wdc.com> wrote:

> index f14ae565af..c2d6e2f766 100644
> --- a/sysdeps/unix/sysv/linux/nanosleep.c
> +++ b/sysdeps/unix/sysv/linux/nanosleep.c
> @@ -25,7 +25,19 @@ int
>  __nanosleep (const struct timespec *requested_time,
>              struct timespec *remaining)
>  {
> +
> +#ifdef __ASSUME_TIME64_SYSCALLS
> +  return SYSCALL_CANCEL (clock_nanosleep_time64, CLOCK_REALTIME, 0,
> +                         requested_time, remaining);
> +#else
> +# ifdef __NR_clock_nanosleep_time64
> +  long int ret = SYSCALL_CANCEL (clock_nanosleep_time64, CLOCK_REALTIME, 0,
> +                                 requested_time, remaining);
> +  if (ret == 0 || errno != ENOSYS)
> +    return ret;
> +# endif
>    return SYSCALL_CANCEL (nanosleep, requested_time, remaining);
> +#endif
>  }

There has to be a type conversion in here somewhere: If timespec
uses 32-bit time_t (on all existing 32-bit architectures), you must not
pass it into __NR_clock_nanosleep_time64, while on builds with
a 64-bit timespec you must not call nanosleep() without conversion.

I suppose you need something like an internal __nanosleep64 (like
your function above, but with the conversion added to the fallback
path) and an internal __nanosleep32 (not calling clock_nanosleep_time64
or doing conversion). Architectures that have always had a 64-bit time_t
don't need the latter of course.

No idea how that fits into the rest of the glibc implementation.

        Arnd

Re: [RFC v2 05/20] sysdeps/nanosleep: Use clock_nanosleep_time64 if avaliable

[Alistair Francis]

On Tue, Jun 25, 2019 at 1:59 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Jun 25, 2019 at 2:11 AM Alistair Francis
> <alistair.francis@wdc.com> wrote:
>
> > index f14ae565af..c2d6e2f766 100644
> > --- a/sysdeps/unix/sysv/linux/nanosleep.c
> > +++ b/sysdeps/unix/sysv/linux/nanosleep.c
> > @@ -25,7 +25,19 @@ int
> >  __nanosleep (const struct timespec *requested_time,
> >              struct timespec *remaining)
> >  {
> > +
> > +#ifdef __ASSUME_TIME64_SYSCALLS
> > +  return SYSCALL_CANCEL (clock_nanosleep_time64, CLOCK_REALTIME, 0,
> > +                         requested_time, remaining);
> > +#else
> > +# ifdef __NR_clock_nanosleep_time64
> > +  long int ret = SYSCALL_CANCEL (clock_nanosleep_time64, CLOCK_REALTIME, 0,
> > +                                 requested_time, remaining);
> > +  if (ret == 0 || errno != ENOSYS)
> > +    return ret;
> > +# endif
> >    return SYSCALL_CANCEL (nanosleep, requested_time, remaining);
> > +#endif
> >  }
>
> There has to be a type conversion in here somewhere: If timespec
> uses 32-bit time_t (on all existing 32-bit architectures), you must not
> pass it into __NR_clock_nanosleep_time64, while on builds with
> a 64-bit timespec you must not call nanosleep() without conversion.
>
> I suppose you need something like an internal __nanosleep64 (like
> your function above, but with the conversion added to the fallback
> path) and an internal __nanosleep32 (not calling clock_nanosleep_time64
> or doing conversion). Architectures that have always had a 64-bit time_t
> don't need the latter of course.

Argh, this is a little messy but I think I have something working.

Alistair

>
> No idea how that fits into the rest of the glibc implementation.
>
>         Arnd

[RFC v2 06/20] sysdeps/futex: Use futex_time64 if avaliable

[Alistair Francis]

The futex syscall isn't avaliable on newer 32-bit architectures
(such as RV32) so if futex_time64 is avaliable lets use that instead.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
 ChangeLog                                    |  1 +
 sysdeps/unix/sysv/linux/lowlevellock-futex.h | 28 ++++++++++++++------
 2 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index b90c5ab60c..a700783ef3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -3,6 +3,7 @@
 	* nptl/thrd_sleep.c: Use clock_nanosleep_time64 instead of nanosleep.
 	* sysdeps/unix/sysv/linux/nanosleep.c: Likewise.
 	* sysdeps/unix/sysv/linux/nanosleep_nocancel.c: Likewise.
+	* sysdeps/unix/sysv/linux/lowlevellock-futex.h: Use __NR_futex_time64 if we don't have __NR_futex.
 
 2019-06-20  Dmitry V. Levin  <ldv@altlinux.org>
 	    Florian Weimer  <fweimer@redhat.com>
diff --git a/sysdeps/unix/sysv/linux/lowlevellock-futex.h b/sysdeps/unix/sysv/linux/lowlevellock-futex.h
index 030a14b8dc..e310542bfa 100644
--- a/sysdeps/unix/sysv/linux/lowlevellock-futex.h
+++ b/sysdeps/unix/sysv/linux/lowlevellock-futex.h
@@ -65,14 +65,26 @@
   (((fl) | FUTEX_PRIVATE_FLAG) ^ (private))
 #endif
 
-#define lll_futex_syscall(nargs, futexp, op, ...)                       \
-  ({                                                                    \
-    INTERNAL_SYSCALL_DECL (__err);                                      \
-    long int __ret = INTERNAL_SYSCALL (futex, __err, nargs, futexp, op, \
-				       __VA_ARGS__);                    \
-    (__glibc_unlikely (INTERNAL_SYSCALL_ERROR_P (__ret, __err))         \
-     ? -INTERNAL_SYSCALL_ERRNO (__ret, __err) : 0);                     \
-  })
+/* __NR_futex isn't defined on all archs (RV32) so use __NR_futex_time64 */
+#ifdef __NR_futex_time64
+# define lll_futex_syscall(nargs, futexp, op, ...)                              \
+   ({                                                                           \
+     INTERNAL_SYSCALL_DECL (__err);                                             \
+     long int __ret = INTERNAL_SYSCALL (futex_time64, __err, nargs, futexp, op, \
+                                        __VA_ARGS__);                           \
+     (__glibc_unlikely (INTERNAL_SYSCALL_ERROR_P (__ret, __err))                \
+      ? -INTERNAL_SYSCALL_ERRNO (__ret, __err) : 0);                            \
+   })
+#else
+# define lll_futex_syscall(nargs, futexp, op, ...)                       \
+   ({                                                                    \
+     INTERNAL_SYSCALL_DECL (__err);                                      \
+     long int __ret = INTERNAL_SYSCALL (futex, __err, nargs, futexp, op, \
+                                        __VA_ARGS__);                    \
+     (__glibc_unlikely (INTERNAL_SYSCALL_ERROR_P (__ret, __err))         \
+      ? -INTERNAL_SYSCALL_ERRNO (__ret, __err) : 0);                     \
+   })
+#endif
 
 #define lll_futex_wait(futexp, val, private) \
   lll_futex_timed_wait (futexp, val, NULL, private)
-- 
2.22.0

Re: [RFC v2 06/20] sysdeps/futex: Use futex_time64 if avaliable

[Florian Weimer]

* Alistair Francis:

> +/* __NR_futex isn't defined on all archs (RV32) so use __NR_futex_time64 */
> +#ifdef __NR_futex_time64
> +# define lll_futex_syscall(nargs, futexp, op, ...)                              \
> +   ({                                                                           \
> +     INTERNAL_SYSCALL_DECL (__err);                                             \
> +     long int __ret = INTERNAL_SYSCALL (futex_time64, __err, nargs, futexp, op, \
> +                                        __VA_ARGS__);                           \
> +     (__glibc_unlikely (INTERNAL_SYSCALL_ERROR_P (__ret, __err))                \
> +      ? -INTERNAL_SYSCALL_ERRNO (__ret, __err) : 0);                            \
> +   })
> +#else
> +# define lll_futex_syscall(nargs, futexp, op, ...)                       \
> +   ({                                                                    \
> +     INTERNAL_SYSCALL_DECL (__err);                                      \
> +     long int __ret = INTERNAL_SYSCALL (futex, __err, nargs, futexp, op, \
> +                                        __VA_ARGS__);                    \
> +     (__glibc_unlikely (INTERNAL_SYSCALL_ERROR_P (__ret, __err))         \
> +      ? -INTERNAL_SYSCALL_ERRNO (__ret, __err) : 0);                     \
> +   })
> +#endif

I don't think a compile-time check in generic code is correct here.  It
will cause binaries to fail to run on older kernels which do not have
the system call.  This is obviously not a concern for 32-bit RISC-V, but
it is not acceptable for i386, for example.

I still think you should define __NR_futex in RV32 <sysdep.h>.

Thanks,
Florian

Re: [RFC v2 06/20] sysdeps/futex: Use futex_time64 if avaliable

[Andreas Schwab]

On Jun 25 2019, Florian Weimer <fweimer@redhat.com> wrote:

> * Alistair Francis:
>
>> +/* __NR_futex isn't defined on all archs (RV32) so use __NR_futex_time64 */
>> +#ifdef __NR_futex_time64
>> +# define lll_futex_syscall(nargs, futexp, op, ...)                              \
>> +   ({                                                                           \
>> +     INTERNAL_SYSCALL_DECL (__err);                                             \
>> +     long int __ret = INTERNAL_SYSCALL (futex_time64, __err, nargs, futexp, op, \
>> +                                        __VA_ARGS__);                           \
>> +     (__glibc_unlikely (INTERNAL_SYSCALL_ERROR_P (__ret, __err))                \
>> +      ? -INTERNAL_SYSCALL_ERRNO (__ret, __err) : 0);                            \
>> +   })
>> +#else
>> +# define lll_futex_syscall(nargs, futexp, op, ...)                       \
>> +   ({                                                                    \
>> +     INTERNAL_SYSCALL_DECL (__err);                                      \
>> +     long int __ret = INTERNAL_SYSCALL (futex, __err, nargs, futexp, op, \
>> +                                        __VA_ARGS__);                    \
>> +     (__glibc_unlikely (INTERNAL_SYSCALL_ERROR_P (__ret, __err))         \
>> +      ? -INTERNAL_SYSCALL_ERRNO (__ret, __err) : 0);                     \
>> +   })
>> +#endif
>
> I don't think a compile-time check in generic code is correct here.  It
> will cause binaries to fail to run on older kernels which do not have
> the system call.  This is obviously not a concern for 32-bit RISC-V, but
> it is not acceptable for i386, for example.
>
> I still think you should define __NR_futex in RV32 <sysdep.h>.

For existing 32-bit archs there needs to be a runtime check (if both
__NR_futex and __NR_futex_time64 are defined).

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."

Re: [RFC v2 06/20] sysdeps/futex: Use futex_time64 if avaliable

[Arnd Bergmann]

On Tue, Jun 25, 2019 at 1:26 PM Andreas Schwab <schwab@suse.de> wrote:
> On Jun 25 2019, Florian Weimer <fweimer@redhat.com> wrote:
> >
> > I don't think a compile-time check in generic code is correct here.  It
> > will cause binaries to fail to run on older kernels which do not have
> > the system call.  This is obviously not a concern for 32-bit RISC-V, but
> > it is not acceptable for i386, for example.
> >
> > I still think you should define __NR_futex in RV32 <sysdep.h>.
>
> For existing 32-bit archs there needs to be a runtime check (if both
> __NR_futex and __NR_futex_time64 are defined).

That opens the question what type this function should take,
because one of the two will require the time argument to be
converted.

For instance pthread_timedjoin_np() is a public interface
that will need an additional version to deal with time64.
Should pthread_timedjoin_np() convert the user timespec
to __timespec64 and pass it down to lll_futex_syscall(),
which then converts it back to timespec before calling
__NR_futex() on 32-bit architectures, or is there a way to
avoid the double conversion?

        Arnd

      Arnd

Re: [RFC v2 06/20] sysdeps/futex: Use futex_time64 if avaliable

[Florian Weimer]

* Arnd Bergmann:

> On Tue, Jun 25, 2019 at 1:26 PM Andreas Schwab <schwab@suse.de> wrote:
>> On Jun 25 2019, Florian Weimer <fweimer@redhat.com> wrote:
>> >
>> > I don't think a compile-time check in generic code is correct here.  It
>> > will cause binaries to fail to run on older kernels which do not have
>> > the system call.  This is obviously not a concern for 32-bit RISC-V, but
>> > it is not acceptable for i386, for example.
>> >
>> > I still think you should define __NR_futex in RV32 <sysdep.h>.
>>
>> For existing 32-bit archs there needs to be a runtime check (if both
>> __NR_futex and __NR_futex_time64 are defined).
>
> That opens the question what type this function should take,
> because one of the two will require the time argument to be
> converted.
>
> For instance pthread_timedjoin_np() is a public interface
> that will need an additional version to deal with time64.
> Should pthread_timedjoin_np() convert the user timespec
> to __timespec64 and pass it down to lll_futex_syscall(),
> which then converts it back to timespec before calling
> __NR_futex() on 32-bit architectures, or is there a way to
> avoid the double conversion?

My expectation is that glibc will not provide a 32-bit struct timespec
for architectures which do not have a 32-bit __NR_futex system call.
It's a 64-bit only world.  Before the 2038 deadline, we will not support
kernels that removed support for the 32-bit system calls.

Based on that, I expect that the 32-bit struct timespec variant of
pthread_timedjoin_np calls futex, and the 64-bit variant (probably named
pthread_timedjoin64_np or something like that, or used by default under
appropriate feature selection macros) will call futex_time64.  This has
the advantage that the type of call is visible at the syscall layer, and
could eventually trigger kenrel warnings.  With translation, that
wouldn't be the case.  It also increases compatibility with seccomp
filters which know of the old system calls, but not the new ones.

Thanks,
Florian

Re: [RFC v2 06/20] sysdeps/futex: Use futex_time64 if avaliable

[Arnd Bergmann]

On Tue, Jun 25, 2019 at 2:07 PM Florian Weimer <fweimer@redhat.com> wrote:
> * Arnd Bergmann:
> > For instance pthread_timedjoin_np() is a public interface
> > that will need an additional version to deal with time64.
> > Should pthread_timedjoin_np() convert the user timespec
> > to __timespec64 and pass it down to lll_futex_syscall(),
> > which then converts it back to timespec before calling
> > __NR_futex() on 32-bit architectures, or is there a way to
> > avoid the double conversion?
>
> My expectation is that glibc will not provide a 32-bit struct timespec
> for architectures which do not have a 32-bit __NR_futex system call.
> It's a 64-bit only world.  Before the 2038 deadline, we will not support
> kernels that removed support for the 32-bit system calls.
>
> Based on that, I expect that the 32-bit struct timespec variant of
> pthread_timedjoin_np calls futex, and the 64-bit variant (probably named
> pthread_timedjoin64_np or something like that, or used by default under
> appropriate feature selection macros) will call futex_time64.  This has
> the advantage that the type of call is visible at the syscall layer, and
> could eventually trigger kenrel warnings.  With translation, that
> wouldn't be the case.  It also increases compatibility with seccomp
> filters which know of the old system calls, but not the new ones.

Ok, that's perfect as far as I'm concerned. From earlier discussions
I had understood that you were planning to avoid the associated
code duplication and only have one internal implementation for
the two external interfaces.

      Arnd

[RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable

[Alistair Francis]

Not all architectures support the obsolete gettimeofday so use the
newer clock_gettime64 syscall if it is avaliable. This fixes RV32
build issues.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
 ChangeLog                              |  1 +
 sysdeps/unix/sysv/linux/gettimeofday.c | 28 ++++++++++++++++++++++++++
 2 files changed, 29 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index a700783ef3..f1c7acb6ab 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -4,6 +4,7 @@
 	* sysdeps/unix/sysv/linux/nanosleep.c: Likewise.
 	* sysdeps/unix/sysv/linux/nanosleep_nocancel.c: Likewise.
 	* sysdeps/unix/sysv/linux/lowlevellock-futex.h: Use __NR_futex_time64 if we don't have __NR_futex.
+	* sysdeps/unix/sysv/linux/gettimeofday.c: Use clock_gettime64 syscall for gettimeofday.
 
 2019-06-20  Dmitry V. Levin  <ldv@altlinux.org>
 	    Florian Weimer  <fweimer@redhat.com>
diff --git a/sysdeps/unix/sysv/linux/gettimeofday.c b/sysdeps/unix/sysv/linux/gettimeofday.c
index a74f03825a..3d2b943123 100644
--- a/sysdeps/unix/sysv/linux/gettimeofday.c
+++ b/sysdeps/unix/sysv/linux/gettimeofday.c
@@ -32,7 +32,35 @@
 int
 __gettimeofday (struct timeval *tv, struct timezone *tz)
 {
+#ifdef __ASSUME_TIME64_SYSCALLS
+  int ret;
+  struct timespec now;
+
+  ret = INLINE_VSYSCALL (clock_gettime64, 2, CLOCK_REALTIME,
+                         &now);
+
+  /* Convert from timespec to timeval */
+  tv->tv_sec = now.tv_sec;
+  tv->tv_usec = now.tv_nsec / 1000;
+
+  return ret;
+#else
+# ifdef __NR_clock_gettime64
+  long int ret;
+  struct timespec now;
+
+  ret = INLINE_VSYSCALL (clock_gettime64, 2, CLOCK_REALTIME,
+                         &now);
+
+  /* Convert from timespec to timeval */
+  tv->tv_sec = now.tv_sec;
+  tv->tv_usec = now.tv_nsec / 1000;
+
+  if (ret == 0 || errno != ENOSYS)
+    return ret;
+# endif
   return INLINE_VSYSCALL (gettimeofday, 2, tv, tz);
+#endif
 }
 libc_hidden_def (__gettimeofday)
 weak_alias (__gettimeofday, gettimeofday)
-- 
2.22.0

Re: [RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable

[Adhemerval Zanella]

On 24/06/2019 21:09, Alistair Francis wrote:
> Not all architectures support the obsolete gettimeofday so use the
> newer clock_gettime64 syscall if it is avaliable. This fixes RV32
> build issues.
> 
> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
> ---
>  ChangeLog                              |  1 +
>  sysdeps/unix/sysv/linux/gettimeofday.c | 28 ++++++++++++++++++++++++++
>  2 files changed, 29 insertions(+)
> 
> diff --git a/ChangeLog b/ChangeLog
> index a700783ef3..f1c7acb6ab 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -4,6 +4,7 @@
>  	* sysdeps/unix/sysv/linux/nanosleep.c: Likewise.
>  	* sysdeps/unix/sysv/linux/nanosleep_nocancel.c: Likewise.
>  	* sysdeps/unix/sysv/linux/lowlevellock-futex.h: Use __NR_futex_time64 if we don't have __NR_futex.
> +	* sysdeps/unix/sysv/linux/gettimeofday.c: Use clock_gettime64 syscall for gettimeofday.
>  
>  2019-06-20  Dmitry V. Levin  <ldv@altlinux.org>
>  	    Florian Weimer  <fweimer@redhat.com>
> diff --git a/sysdeps/unix/sysv/linux/gettimeofday.c b/sysdeps/unix/sysv/linux/gettimeofday.c
> index a74f03825a..3d2b943123 100644
> --- a/sysdeps/unix/sysv/linux/gettimeofday.c
> +++ b/sysdeps/unix/sysv/linux/gettimeofday.c
> @@ -32,7 +32,35 @@
>  int
>  __gettimeofday (struct timeval *tv, struct timezone *tz)
>  {
> +#ifdef __ASSUME_TIME64_SYSCALLS
> +  int ret;
> +  struct timespec now;
> +
> +  ret = INLINE_VSYSCALL (clock_gettime64, 2, CLOCK_REALTIME,
> +                         &now);
> +
> +  /* Convert from timespec to timeval */
> +  tv->tv_sec = now.tv_sec;
> +  tv->tv_usec = now.tv_nsec / 1000;
> +
> +  return ret;
> +#else
> +# ifdef __NR_clock_gettime64
> +  long int ret;
> +  struct timespec now;
> +
> +  ret = INLINE_VSYSCALL (clock_gettime64, 2, CLOCK_REALTIME,
> +                         &now);
> +
> +  /* Convert from timespec to timeval */
> +  tv->tv_sec = now.tv_sec;
> +  tv->tv_usec = now.tv_nsec / 1000;
> +
> +  if (ret == 0 || errno != ENOSYS)
> +    return ret;
> +# endif
>    return INLINE_VSYSCALL (gettimeofday, 2, tv, tz);
> +#endif
>  }
>  libc_hidden_def (__gettimeofday)
>  weak_alias (__gettimeofday, gettimeofday)
> 

Wouldn't be simpler to just call __clock_gettime instead:

--
__gettimeofday (struct timeval *tv, struct timezone *tz)
{
  if (tv == NULL)
    return 0;

  struct timespec ts;
  __clock_gettime (CLOCK_REALTIME, &ts);
  tv->tv_sec = ts.tv_sec;
  tv->tv_usec = (__suseconds_t)ts.tv_nsec / 1000;
  return 0;
}
--

From the patch 'linux: Provide __clock_settime64 implementation' internal
include/time.h will redefine __clock_gettime to __clock_gettime64 if the
case.

Re: [RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable

[Alistair Francis]

On Thu, Jun 27, 2019 at 6:15 AM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 24/06/2019 21:09, Alistair Francis wrote:
> > Not all architectures support the obsolete gettimeofday so use the
> > newer clock_gettime64 syscall if it is avaliable. This fixes RV32
> > build issues.
> >
> > Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
> > ---
> >  ChangeLog                              |  1 +
> >  sysdeps/unix/sysv/linux/gettimeofday.c | 28 ++++++++++++++++++++++++++
> >  2 files changed, 29 insertions(+)
> >
> > diff --git a/ChangeLog b/ChangeLog
> > index a700783ef3..f1c7acb6ab 100644
> > --- a/ChangeLog
> > +++ b/ChangeLog
> > @@ -4,6 +4,7 @@
> >       * sysdeps/unix/sysv/linux/nanosleep.c: Likewise.
> >       * sysdeps/unix/sysv/linux/nanosleep_nocancel.c: Likewise.
> >       * sysdeps/unix/sysv/linux/lowlevellock-futex.h: Use __NR_futex_time64 if we don't have __NR_futex.
> > +     * sysdeps/unix/sysv/linux/gettimeofday.c: Use clock_gettime64 syscall for gettimeofday.
> >
> >  2019-06-20  Dmitry V. Levin  <ldv@altlinux.org>
> >           Florian Weimer  <fweimer@redhat.com>
> > diff --git a/sysdeps/unix/sysv/linux/gettimeofday.c b/sysdeps/unix/sysv/linux/gettimeofday.c
> > index a74f03825a..3d2b943123 100644
> > --- a/sysdeps/unix/sysv/linux/gettimeofday.c
> > +++ b/sysdeps/unix/sysv/linux/gettimeofday.c
> > @@ -32,7 +32,35 @@
> >  int
> >  __gettimeofday (struct timeval *tv, struct timezone *tz)
> >  {
> > +#ifdef __ASSUME_TIME64_SYSCALLS
> > +  int ret;
> > +  struct timespec now;
> > +
> > +  ret = INLINE_VSYSCALL (clock_gettime64, 2, CLOCK_REALTIME,
> > +                         &now);
> > +
> > +  /* Convert from timespec to timeval */
> > +  tv->tv_sec = now.tv_sec;
> > +  tv->tv_usec = now.tv_nsec / 1000;
> > +
> > +  return ret;
> > +#else
> > +# ifdef __NR_clock_gettime64
> > +  long int ret;
> > +  struct timespec now;
> > +
> > +  ret = INLINE_VSYSCALL (clock_gettime64, 2, CLOCK_REALTIME,
> > +                         &now);
> > +
> > +  /* Convert from timespec to timeval */
> > +  tv->tv_sec = now.tv_sec;
> > +  tv->tv_usec = now.tv_nsec / 1000;
> > +
> > +  if (ret == 0 || errno != ENOSYS)
> > +    return ret;
> > +# endif
> >    return INLINE_VSYSCALL (gettimeofday, 2, tv, tz);
> > +#endif
> >  }
> >  libc_hidden_def (__gettimeofday)
> >  weak_alias (__gettimeofday, gettimeofday)
> >
>
> Wouldn't be simpler to just call __clock_gettime instead:
>
> --
> __gettimeofday (struct timeval *tv, struct timezone *tz)
> {
>   if (tv == NULL)
>     return 0;
>
>   struct timespec ts;
>   __clock_gettime (CLOCK_REALTIME, &ts);
>   tv->tv_sec = ts.tv_sec;
>   tv->tv_usec = (__suseconds_t)ts.tv_nsec / 1000;
>   return 0;
> }
> --
>
> From the patch 'linux: Provide __clock_settime64 implementation' internal
> include/time.h will redefine __clock_gettime to __clock_gettime64 if the
> case.

The version of this patch that I have only implements __clock_settime
and not __clock_gettime.

Alistair

Re: [RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable

[Joseph Myers]

On Mon, 24 Jun 2019, Alistair Francis wrote:

> Not all architectures support the obsolete gettimeofday so use the
> newer clock_gettime64 syscall if it is avaliable. This fixes RV32
> build issues.

A key question when using newer syscalls to implement gettimeofday or 
settimeofday, which the commit message needs to answer, is: what are the 
semantics for how the obsolete tz argument is handled, if not NULL?

I'd expect the proposed commit message to include a discussion of what the 
semantics are for that obsolete argument in Linux kernel versions 
supported by glibc, and what the semantics are for that argument in glibc 
when some other syscall gets used by glibc.

For example, I'd expect that if tz is not NULL, any implementation using 
other syscalls would at least fill in some dummy values in *tz, if that's 
what the gettimeofday syscall would do.  And on architectures where the 
gettimeofday / settimeofday syscalls exist, if it is the case that some 
information gets passed from settimeofday to gettimeofday through this 
argument, I'd expect that information to continue to get passed through 
rather than being lost through the use of newer syscalls.  (You could 
reasonably argue for not supporting anything with that argument in the 
_TIME_BITS=64 case, but there could still be issues of keeping ABI 
compatibility for this argument for existing ABIs with 32-bit time, unless 
the current kernel semantics don't actually support doing anything with 
this argument anyway.  In any case, we need that explanation of current 
semantics in order to review any semantic changes from the patch.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable

[Alistair Francis]

On Wed, Jul 24, 2019 at 1:22 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Mon, 24 Jun 2019, Alistair Francis wrote:
>
> > Not all architectures support the obsolete gettimeofday so use the
> > newer clock_gettime64 syscall if it is avaliable. This fixes RV32
> > build issues.
>
> A key question when using newer syscalls to implement gettimeofday or
> settimeofday, which the commit message needs to answer, is: what are the
> semantics for how the obsolete tz argument is handled, if not NULL?
>
> I'd expect the proposed commit message to include a discussion of what the
> semantics are for that obsolete argument in Linux kernel versions
> supported by glibc, and what the semantics are for that argument in glibc
> when some other syscall gets used by glibc.

Yep, I missed this. I have already added it to the commit message of
the next version.

    This has the side effect of not setting the struct timezone *tz variable
    if __ASSUME_TIME64_SYSCALLS or __NR_clock_gettime64 is defined. There
    are two things to consider here:
     - 32-bit systems with __ARCH_WANT_TIME32_SYSCALLS not defined have to
       way to get the struct timezone via a syscall.
     - The Linux documentation says that "The use of the timezone structure
       is obsolete; the tz argument should normally be specified as NULL."
       So let's not worry about it.

Alistair

>
> For example, I'd expect that if tz is not NULL, any implementation using
> other syscalls would at least fill in some dummy values in *tz, if that's
> what the gettimeofday syscall would do.  And on architectures where the
> gettimeofday / settimeofday syscalls exist, if it is the case that some
> information gets passed from settimeofday to gettimeofday through this
> argument, I'd expect that information to continue to get passed through
> rather than being lost through the use of newer syscalls.  (You could
> reasonably argue for not supporting anything with that argument in the
> _TIME_BITS=64 case, but there could still be issues of keeping ABI
> compatibility for this argument for existing ABIs with 32-bit time, unless
> the current kernel semantics don't actually support doing anything with
> this argument anyway.  In any case, we need that explanation of current
> semantics in order to review any semantic changes from the patch.)
>
> --
> Joseph S. Myers
> joseph@codesourcery.com

Re: [RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable

[Arnd Bergmann]

On Thu, Jul 25, 2019 at 1:03 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Wed, Jul 24, 2019 at 1:22 PM Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > On Mon, 24 Jun 2019, Alistair Francis wrote:
> >
> > > Not all architectures support the obsolete gettimeofday so use the
> > > newer clock_gettime64 syscall if it is avaliable. This fixes RV32
> > > build issues.
> >
> > A key question when using newer syscalls to implement gettimeofday or
> > settimeofday, which the commit message needs to answer, is: what are the
> > semantics for how the obsolete tz argument is handled, if not NULL?
> >
> > I'd expect the proposed commit message to include a discussion of what the
> > semantics are for that obsolete argument in Linux kernel versions
> > supported by glibc, and what the semantics are for that argument in glibc
> > when some other syscall gets used by glibc.
>
> Yep, I missed this. I have already added it to the commit message of
> the next version.
>
>     This has the side effect of not setting the struct timezone *tz variable
>     if __ASSUME_TIME64_SYSCALLS or __NR_clock_gettime64 is defined. There
>     are two things to consider here:
>      - 32-bit systems with __ARCH_WANT_TIME32_SYSCALLS not defined have to
>        way to get the struct timezone via a syscall.
>      - The Linux documentation says that "The use of the timezone structure
>        is obsolete; the tz argument should normally be specified as NULL."
>        So let's not worry about it.

That's fine with me, but I would like to point out that the omission of the
timezone get/set interfaces was not intentional. I think I considered the
POSIX man page (which says undefined behavior) and I ported musl
over (which ignores the timezone argument), but I did not realize that
glibc passes it on and that there are applications that make use of that.

Using debian code search, I found hwclock as something that sets
the timezone at boot, and there are a small number of kernel files that
use the information at runtime (full list below). If we want to keep
the traditional settimeofday()/gettimeofday() behavior working, a new
kernel interface could be added, e.g. in one of the reserved fields
of clock_adjtime(), or as a new syscall.

       Arnd
---
drivers/media/platform/vivid/vivid-rds-gen.c:
(sys_tz.tz_minuteswest >= 0 ? 0x20 : 0) |
drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c:
record->end_utc_bias = cpu_to_le16(sys_tz.tz_minuteswest * 60);
drivers/scsi/3w-9xxx.c: local_time = (u32)(ktime_get_real_seconds() -
(sys_tz.tz_minuteswest * 60));
drivers/scsi/3w-sas.c:  local_time = (u32)(ktime_get_real_seconds() -
(sys_tz.tz_minuteswest * 60));
drivers/scsi/aacraid/commsup.c: local_time = (now->tv_sec -
(sys_tz.tz_minuteswest * 60));
drivers/scsi/arcmsr/arcmsr_hba.c:
time64_to_tm(ktime_get_real_seconds(), -sys_tz.tz_minuteswest * 60,
&tm);
drivers/scsi/mvumi.c:           local_time = (time -
(sys_tz.tz_minuteswest * 60));
drivers/scsi/smartpqi/smartpqi_init.c:  time64_to_tm(local_time,
-sys_tz.tz_minuteswest * 60, &tm);
fs/affs/amigaffs.c:     secs -= sys_tz.tz_minuteswest * 60 + ((8 * 365
+ 2) * 24 * 60 * 60);
fs/affs/inode.c:                         sys_tz.tz_minuteswest * 60;
fs/fat/misc.c:         sys_tz.tz_minuteswest) * SECS_PER_MIN;
fs/hfs/hfs_fs.h:        return ut + sys_tz.tz_minuteswest * 60;
fs/hfs/inode.c: HFS_I(inode)->tz_secondswest = sys_tz.tz_minuteswest * 60;
fs/hfs/sysdep.c:        diff = sys_tz.tz_minuteswest * 60 -
HFS_I(inode)->tz_secondswest;
fs/hpfs/hpfs_fn.h:      return t + sys_tz.tz_minuteswest * 60 +
hpfs_sb(s)->sb_timeshift;
fs/udf/udftime.c:       offset = -sys_tz.tz_minuteswest;
kernel/debug/kdb/kdb_main.c:            sys_tz.tz_minuteswest);
kernel/time/ntp.c:              adjust.tv_sec -= (sys_tz.tz_minuteswest * 60);
kernel/time/timekeeping.c:      if (sys_tz.tz_minuteswest != 0) {
kernel/time/vsyscall.c:         vdata[CS_HRES_COARSE].tz_minuteswest =
sys_tz.tz_minuteswest;
lib/vdso/gettimeofday.c:                tz->tz_minuteswest =
vd[CS_HRES_COARSE].tz_minuteswest;
net/netfilter/xt_time.c:                stamp -= 60 * sys_tz.tz_minuteswest;

Re: [RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable

[Paul Eggert]

Arnd Bergmann wrote:
> If we want to keep
> the traditional settimeofday()/gettimeofday() behavior working, a new
> kernel interface could be added

Let's not. That behavior was a bad idea even in the 1980s, and applications 
stopped using it decades ago. It has been completely obsoleted by TZ strings.

Re: [RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable

[Zack Weinberg]

On Thu, Jul 25, 2019 at 1:03 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> Arnd Bergmann wrote:
> > If we want to keep
> > the traditional settimeofday()/gettimeofday() behavior working, a new
> > kernel interface could be added
>
> Let's not. That behavior was a bad idea even in the 1980s, and applications
> stopped using it decades ago. It has been completely obsoleted by TZ strings.

Do we think we could get away with having both functions fail (with
EINVAL) whenever the tz argument is non-null?

zw

Re: [RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable

[Arnd Bergmann]

On Thu, Jul 25, 2019 at 7:21 PM Zack Weinberg <zackw@panix.com> wrote:
>
> On Thu, Jul 25, 2019 at 1:03 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> >
> > Arnd Bergmann wrote:
> > > If we want to keep
> > > the traditional settimeofday()/gettimeofday() behavior working, a new
> > > kernel interface could be added
> >
> > Let's not. That behavior was a bad idea even in the 1980s, and applications
> > stopped using it decades ago. It has been completely obsoleted by TZ strings.
>
> Do we think we could get away with having both functions fail (with
> EINVAL) whenever the tz argument is non-null?

From my findings at Debian code search, I found code like

struct timeval my_gettime(void)
{
     struct timezone tz_ignored;
     struct timeval tv;
     gettimeofday(&tv, &tz_ignored);
     return tv;
}

In this case, the safer choice would be to silently ignore it.

Another alternative would be to hide the definition of 'struct timezone'
in the libc headers and only leave a forward declaration.

That would lead to a compile-time error here, and force a change in
any source code that actually tries to use the timezone in a
meaningful way.

We also need to deal with other compile-time failures for code that
is not y2038 safe (e.g. __NR_futex users), so this may be a reasonable
compromise.

       Arnd

Re: [RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable

[Florian Weimer]

* Arnd Bergmann:

> On Thu, Jul 25, 2019 at 7:21 PM Zack Weinberg <zackw@panix.com> wrote:
>>
>> On Thu, Jul 25, 2019 at 1:03 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>> >
>> > Arnd Bergmann wrote:
>> > > If we want to keep
>> > > the traditional settimeofday()/gettimeofday() behavior working, a new
>> > > kernel interface could be added
>> >
>> > Let's not. That behavior was a bad idea even in the 1980s, and applications
>> > stopped using it decades ago. It has been completely obsoleted by TZ strings.
>>
>> Do we think we could get away with having both functions fail (with
>> EINVAL) whenever the tz argument is non-null?
>
> From my findings at Debian code search, I found code like
>
> struct timeval my_gettime(void)
> {
>      struct timezone tz_ignored;
>      struct timeval tv;
>      gettimeofday(&tv, &tz_ignored);
>      return tv;
> }
>
> In this case, the safer choice would be to silently ignore it.
>
> Another alternative would be to hide the definition of 'struct timezone'
> in the libc headers and only leave a forward declaration.

Renaming the struct timezone members might be sufficient.  Then the code
above would still compile, but something that actually depends on the
struct timezone data would not.

Thanks,
Florian

Re: [RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable

[Zack Weinberg]

On Fri, Jul 26, 2019 at 9:01 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Arnd Bergmann:
>
> > On Thu, Jul 25, 2019 at 7:21 PM Zack Weinberg <zackw@panix.com> wrote:
> >>
> >> On Thu, Jul 25, 2019 at 1:03 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> >> >
> >> > Arnd Bergmann wrote:
> >> > > If we want to keep
> >> > > the traditional settimeofday()/gettimeofday() behavior working, a new
> >> > > kernel interface could be added
> >> >
> >> > Let's not. That behavior was a bad idea even in the 1980s, and applications
> >> > stopped using it decades ago. It has been completely obsoleted by TZ strings.
> >>
> >> Do we think we could get away with having both functions fail (with
> >> EINVAL) whenever the tz argument is non-null?
> >
> > From my findings at Debian code search, I found code like
> >
> > struct timeval my_gettime(void)
> > {
> >      struct timezone tz_ignored;
> >      struct timeval tv;
> >      gettimeofday(&tv, &tz_ignored);
> >      return tv;
> > }
> >
> > In this case, the safer choice would be to silently ignore it.
> >
> > Another alternative would be to hide the definition of 'struct timezone'
> > in the libc headers and only leave a forward declaration.
>
> Renaming the struct timezone members might be sufficient.  Then the code
> above would still compile, but something that actually depends on the
> struct timezone data would not.

I like this idea.  We could escalate to hiding the definition later.

zw

Re: [RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable

[Joseph Myers]

On Wed, 24 Jul 2019, Alistair Francis wrote:

> > A key question when using newer syscalls to implement gettimeofday or
> > settimeofday, which the commit message needs to answer, is: what are the
> > semantics for how the obsolete tz argument is handled, if not NULL?
> >
> > I'd expect the proposed commit message to include a discussion of what the
> > semantics are for that obsolete argument in Linux kernel versions
> > supported by glibc, and what the semantics are for that argument in glibc
> > when some other syscall gets used by glibc.
> 
> Yep, I missed this. I have already added it to the commit message of
> the next version.
> 
>     This has the side effect of not setting the struct timezone *tz variable
>     if __ASSUME_TIME64_SYSCALLS or __NR_clock_gettime64 is defined. There
>     are two things to consider here:
>      - 32-bit systems with __ARCH_WANT_TIME32_SYSCALLS not defined have to
>        way to get the struct timezone via a syscall.
>      - The Linux documentation says that "The use of the timezone structure
>        is obsolete; the tz argument should normally be specified as NULL."
>        So let's not worry about it.

What I'd like to see in the commit message is:

1. A detailed discussion of what the current ABI is regarding this 
argument (not how some systems used to use it for timezone handling, just 
how the Linux kernel handles it as an argument to the gettimeofday and 
settimeofday syscalls).

2. A discussion of how the patch achieves maximum ABI and API 
compatibility with existing programs using this argument (and in turn, the 
patch should be implemented so as to achieve that compatibility).  There, 
I'd suggest:

(a) For existing glibc ABIs, the tz value should continue to be passed to 
/ from the kernel exactly as at present (which might mean continuing to 
use the old syscalls when implementing those functions, even when newer 
syscalls are available - whether this value is passed to/from the kernel 
should not depend on __ASSUME_TIME64_SYSCALLS).

(b) For new ABIs, including _TIME_BITS=64 for systems that currently have 
32-bit time in glibc, you can make a reasonable case for not passing the 
argument to / from the kernel, at least if the special case mentioned in 
the settimeofday manpage for the hardware clock being in local time can be 
justified as being irrelevant for such ABIs.  But in this case I'd still 
think you should at least set *tz to some sensible default value in 
gettimeofday rather than leaving it as uninitialized data.

(Thus the tz argument might result in gettimeofday being an exception to 
the normal rule of 32-bit functions being thin wrappers around 64-bit 
ones, if the _TIME_BITS=64 version ends up handling tz differently from 
how the 32-bit syscall does.)

-- 
Joseph S. Myers
joseph@codesourcery.com

[RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Alistair Francis]

If the waitid syscall is avaliable let's use that as waitpid
and wait4 aren't always avaliable (they aren't avaliable on RV32).

Unfortunately waitid is substantially differnt to waitpid and wait4, so
the conversion ends up being complex.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
 ChangeLog                                  |  3 ++
 sysdeps/unix/sysv/linux/wait.c             | 21 ++++++++-
 sysdeps/unix/sysv/linux/waitpid.c          | 54 ++++++++++++++++++++++
 sysdeps/unix/sysv/linux/waitpid_nocancel.c | 53 +++++++++++++++++++++
 4 files changed, 129 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index f1c7acb6ab..9ed9bea8b1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -5,6 +5,9 @@
 	* sysdeps/unix/sysv/linux/nanosleep_nocancel.c: Likewise.
 	* sysdeps/unix/sysv/linux/lowlevellock-futex.h: Use __NR_futex_time64 if we don't have __NR_futex.
 	* sysdeps/unix/sysv/linux/gettimeofday.c: Use clock_gettime64 syscall for gettimeofday.
+	* sysdeps/unix/sysv/linux/wait.c: Use __NR_waitid if avaliable.
+	* sysdeps/unix/sysv/linux/waitpid.c: Likewise.
+	* sysdeps/unix/sysv/linux/waitpid_nocancel.c: Likewise.
 
 2019-06-20  Dmitry V. Levin  <ldv@altlinux.org>
 	    Florian Weimer  <fweimer@redhat.com>
diff --git a/sysdeps/unix/sysv/linux/wait.c b/sysdeps/unix/sysv/linux/wait.c
index 498bd1c095..67b94776a4 100644
--- a/sysdeps/unix/sysv/linux/wait.c
+++ b/sysdeps/unix/sysv/linux/wait.c
@@ -26,8 +26,25 @@
 pid_t
 __libc_wait (int *stat_loc)
 {
-  pid_t result = SYSCALL_CANCEL (wait4, WAIT_ANY, stat_loc, 0,
-				 (struct rusage *) NULL);
+  pid_t result;
+
+#ifdef __NR_waitid
+  siginfo_t infop;
+
+  result = SYSCALL_CANCEL (waitid, P_ALL, 0, &infop, WEXITED);
+
+  if (stat_loc) {
+    *stat_loc = infop.si_status;
+  }
+
+  if (result == 0) {
+    result = infop.si_pid;
+  }
+#else
+  result = SYSCALL_CANCEL (wait4, WAIT_ANY, stat_loc, 0,
+                           (struct rusage *) NULL);
+#endif
+
   return result;
 }
 
diff --git a/sysdeps/unix/sysv/linux/waitpid.c b/sysdeps/unix/sysv/linux/waitpid.c
index f0897574c0..8c0e2f882a 100644
--- a/sysdeps/unix/sysv/linux/waitpid.c
+++ b/sysdeps/unix/sysv/linux/waitpid.c
@@ -20,12 +20,66 @@
 #include <sysdep-cancel.h>
 #include <stdlib.h>
 #include <sys/wait.h>
+#include <unistd.h>
 
 __pid_t
 __waitpid (__pid_t pid, int *stat_loc, int options)
 {
 #ifdef __NR_waitpid
   return SYSCALL_CANCEL (waitpid, pid, stat_loc, options);
+#elif defined(__NR_waitid)
+  int ret, waitid_options = 0;
+  idtype_t idtype = P_PID;
+  siginfo_t infop;
+
+  /* Set this to zero so we can test if WNOHANG was specified in options
+   * and there were no children in a waitable state. This is required to match
+   * waitid() behaviour.
+   */
+  infop.si_pid = 0;
+
+  if (pid < -1) {
+    idtype = P_PGID;
+    pid *= -1;
+  } else if (pid == -1) {
+    idtype = P_ALL;
+  } else if (pid == 0) {
+    idtype = P_PGID;
+    pid = getpgrp();
+  }
+
+  /* Convert the older WNOHANG, WUNTRACED and WCONTINUED options to the newer
+   * ones uses for waitid().
+   */
+  if (options | WNOHANG) {
+    waitid_options |= WNOHANG;
+  }
+  if (options | WUNTRACED) {
+    waitid_options |= WSTOPPED;
+  }
+  if (options | WCONTINUED) {
+    waitid_options |= WCONTINUED;
+  }
+
+  /* waitid() requires at least WEXITED, WSTOPPED or WCONTINUED to be
+   * specified. If none were specified default to WEXITED as that is what
+   * waitpid() and wait4() do.
+   */
+  if (options == 0 || waitid_options == WNOHANG) {
+    waitid_options |= WEXITED;
+  }
+
+  ret = SYSCALL_CANCEL (waitid, idtype, pid, &infop, waitid_options);
+
+  if (stat_loc) {
+    *stat_loc = infop.si_status;
+  }
+
+  if (ret == 0) {
+    return infop.si_pid;
+  }
+
+  return ret;
 #else
   return SYSCALL_CANCEL (wait4, pid, stat_loc, options, NULL);
 #endif
diff --git a/sysdeps/unix/sysv/linux/waitpid_nocancel.c b/sysdeps/unix/sysv/linux/waitpid_nocancel.c
index 89e36a5c0b..d14b7bf260 100644
--- a/sysdeps/unix/sysv/linux/waitpid_nocancel.c
+++ b/sysdeps/unix/sysv/linux/waitpid_nocancel.c
@@ -27,6 +27,59 @@ __waitpid_nocancel (__pid_t pid, int *stat_loc, int options)
 {
 #ifdef __NR_waitpid
   return INLINE_SYSCALL_CALL (waitpid, pid, stat_loc, options);
+#elif defined(__NR_waitid)
+  int ret, waitid_options = 0;
+  idtype_t idtype = P_PID;
+  siginfo_t infop;
+
+  /* Set this to zero so we can test if WNOHANG was specified in options
+   * and there were no children in a waitable state. This is required to match
+   * waitid() behaviour.
+   */
+  infop.si_pid = 0;
+
+  if (pid < -1) {
+    idtype = P_PGID;
+    pid *= -1;
+  } else if (pid == -1) {
+    idtype = P_ALL;
+  } else if (pid == 0) {
+    idtype = P_PGID;
+    pid = getpgrp();
+  }
+
+  /* Convert the older WNOHANG, WUNTRACED and WCONTINUED options to the newer
+   * ones uses for waitid().
+   */
+  if (options | WNOHANG) {
+    waitid_options |= WNOHANG;
+  }
+  if (options | WUNTRACED) {
+    waitid_options |= WSTOPPED;
+  }
+  if (options | WCONTINUED) {
+    waitid_options |= WCONTINUED;
+  }
+
+  /* waitid() requires at least WEXITED, WSTOPPED or WCONTINUED to be
+   * specified. If none were specified default to WEXITED as that is what
+   * waitpid() and wait4() do.
+   */
+  if (options == 0 || waitid_options == WNOHANG) {
+    waitid_options |= WEXITED;
+  }
+
+  ret = INLINE_SYSCALL_CALL (waitid, idtype, pid, &infop, waitid_options);
+
+  if (stat_loc) {
+    *stat_loc = infop.si_status;
+  }
+
+  if (ret == 0) {
+    return infop.si_pid;
+  }
+
+  return ret;
 #else
   return INLINE_SYSCALL_CALL (wait4, pid, stat_loc, options, NULL);
 #endif
-- 
2.22.0

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Andreas Schwab]

On Jun 24 2019, Alistair Francis <alistair.francis@wdc.com> wrote:

> +  if (options | WNOHANG) {
> +    waitid_options |= WNOHANG;
> +  }
> +  if (options | WUNTRACED) {
> +    waitid_options |= WSTOPPED;
> +  }
> +  if (options | WCONTINUED) {
> +    waitid_options |= WCONTINUED;
> +  }

Surely that's not going to work out.

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."

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Zack Weinberg]

On Mon, Jun 24, 2019 at 8:12 PM Alistair Francis
<alistair.francis@wdc.com> wrote:
>
> If the waitid syscall is avaliable let's use that as waitpid
> and wait4 aren't always avaliable (they aren't avaliable on RV32).

wait4 does something that can't be done any other way (retrieve
resource usage information), RV32 should have it.

zw

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Florian Weimer]

* Zack Weinberg:

> On Mon, Jun 24, 2019 at 8:12 PM Alistair Francis
> <alistair.francis@wdc.com> wrote:
>>
>> If the waitid syscall is avaliable let's use that as waitpid
>> and wait4 aren't always avaliable (they aren't avaliable on RV32).
>
> wait4 does something that can't be done any other way (retrieve
> resource usage information), RV32 should have it.

I think the problem is that the kernel provides wait4 under a different
name because struct rusage has two fields of struct timeval.

I think this needs to be covered by the syscall renaming mechanism, to
get a working wait4, and not changes to wait.

Thanks,
Florian

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Arnd Bergmann]

On Tue, Jun 25, 2019 at 1:07 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Zack Weinberg:
>
> > On Mon, Jun 24, 2019 at 8:12 PM Alistair Francis
> > <alistair.francis@wdc.com> wrote:
> >>
> >> If the waitid syscall is avaliable let's use that as waitpid
> >> and wait4 aren't always avaliable (they aren't avaliable on RV32).
> >
> > wait4 does something that can't be done any other way (retrieve
> > resource usage information), RV32 should have it.
>
> I think the problem is that the kernel provides wait4 under a different
> name because struct rusage has two fields of struct timeval.
>
> I think this needs to be covered by the syscall renaming mechanism, to
> get a working wait4, and not changes to wait.

The kernel system call waitid() is a superset of glibc's wait4() and
waitid(), it has an extra rusage argument.

Originally, my plan was to replace kernel's waitid() with
a waitid_time64() that takes an updated rusage structure,
but that never happened.

I still left wait4() commented out since it should not be
needed when the kernel has waitid(). I have an implementation
of wait4() based on waitid() that I did for musl and tested
successfully with ltp, see [1].
Unless I did something very wrong there, you should be able
to use something like this in glibc.

Similar coversions of timeval have to be done in getrusage(),
getitimer() and setitimer(), all of which expect a 32-bit
timeval couting elapsed time (so no overflow in y2038).
These need to be converted to the 64-bit timeval in the
public glibc interface.

       Arnd

[1] https://git.linaro.org/people/arnd/musl-y2038.git/tree/src/linux/wait4.c

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Florian Weimer]

* Arnd Bergmann:

> The kernel system call waitid() is a superset of glibc's wait4() and
> waitid(), it has an extra rusage argument.
>
> Originally, my plan was to replace kernel's waitid() with
> a waitid_time64() that takes an updated rusage structure,
> but that never happened.
>
> I still left wait4() commented out since it should not be
> needed when the kernel has waitid(). I have an implementation
> of wait4() based on waitid() that I did for musl and tested
> successfully with ltp, see [1].
> Unless I did something very wrong there, you should be able
> to use something like this in glibc.
>
> Similar coversions of timeval have to be done in getrusage(),
> getitimer() and setitimer(), all of which expect a 32-bit
> timeval couting elapsed time (so no overflow in y2038).
> These need to be converted to the 64-bit timeval in the
> public glibc interface.

Does this means that RV32 will use a 32-bit struct timeval in those
system calls?  Even if everything else 64-bit?

Thanks,
Florian

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Arnd Bergmann]

On Tue, Jun 25, 2019 at 2:10 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Arnd Bergmann:
>
> > The kernel system call waitid() is a superset of glibc's wait4() and
> > waitid(), it has an extra rusage argument.
> >
> > Originally, my plan was to replace kernel's waitid() with
> > a waitid_time64() that takes an updated rusage structure,
> > but that never happened.
> >
> > I still left wait4() commented out since it should not be
> > needed when the kernel has waitid(). I have an implementation
> > of wait4() based on waitid() that I did for musl and tested
> > successfully with ltp, see [1].
> > Unless I did something very wrong there, you should be able
> > to use something like this in glibc.
> >
> > Similar coversions of timeval have to be done in getrusage(),
> > getitimer() and setitimer(), all of which expect a 32-bit
> > timeval couting elapsed time (so no overflow in y2038).
> > These need to be converted to the 64-bit timeval in the
> > public glibc interface.
>
> Does this means that RV32 will use a 32-bit struct timeval in those
> system calls?  Even if everything else 64-bit?

Correct. Only those four (all deprecated but still used) system calls,
as we could not agree on a new interface before 5.1, and there
is no urgency for deployment when they can be emulated.

I agree this is ugly, sorry for having dropped the mess into your
area instead of fixing it in the kernel.

        Arnd

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Arnd Bergmann]

On Tue, Jun 25, 2019 at 3:29 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, Jun 25, 2019 at 2:10 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> > Does this means that RV32 will use a 32-bit struct timeval in those
> > system calls?  Even if everything else 64-bit?
>
> Correct. Only those four (all deprecated but still used) system calls,
> as we could not agree on a new interface before 5.1, and there
> is no urgency for deployment when they can be emulated.

Correction: getrusage() is still a recommended interface in POSIX.1-2017
with no nanosecond based replacement, while wait4(), getitimer() and
getrusage() are all obsolete but cannot be implemented on top of other
POSIX system calls.

        Arnd

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Florian Weimer]

* Arnd Bergmann:

> On Tue, Jun 25, 2019 at 3:29 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tue, Jun 25, 2019 at 2:10 PM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> > Does this means that RV32 will use a 32-bit struct timeval in those
>> > system calls?  Even if everything else 64-bit?
>>
>> Correct. Only those four (all deprecated but still used) system calls,
>> as we could not agree on a new interface before 5.1, and there
>> is no urgency for deployment when they can be emulated.
>
> Correction: getrusage() is still a recommended interface in POSIX.1-2017
> with no nanosecond based replacement, while wait4(), getitimer() and
> getrusage() are all obsolete but cannot be implemented on top of other
> POSIX system calls.

This makes me rather unhappy.  I also don't see the benefit of renaming
all time-related system calls for new architectures.  Oh well.  I hope
someone will figure out how to integrate this smoothly into glibc.

Thanks,
Florian

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Arnd Bergmann]

On Tue, Jun 25, 2019 at 3:47 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Arnd Bergmann:
>
> > On Tue, Jun 25, 2019 at 3:29 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Tue, Jun 25, 2019 at 2:10 PM Florian Weimer <fweimer@redhat.com> wrote:
> >>
> >> > Does this means that RV32 will use a 32-bit struct timeval in those
> >> > system calls?  Even if everything else 64-bit?
> >>
> >> Correct. Only those four (all deprecated but still used) system calls,
> >> as we could not agree on a new interface before 5.1, and there
> >> is no urgency for deployment when they can be emulated.
> >
> > Correction: getrusage() is still a recommended interface in POSIX.1-2017
> > with no nanosecond based replacement, while wait4(), getitimer() and
> > getrusage() are all obsolete but cannot be implemented on top of other
> > POSIX system calls.
>
> This makes me rather unhappy.  I also don't see the benefit of renaming
> all time-related system calls for new architectures.

What got renamed? I was trying very hard to make it as consistent
and easy as possible. There is a strict mapping of __NR_* macros
to argument types for each system call [1], so e.g. __kernel_timespec
will always be used together with system calls named *time64(),
while the old system calls always refer to the traditional
"struct timespec {long tv_sec; long tv_nsec;}" type. This is the
same way that loff_t gets handled, so I assumed that all C libraries
would know how to deal with this well.

> Oh well.  I hope
> someone will figure out how to integrate this smoothly into glibc.

Integrating this should actually be easier than the other system calls
since you only need to implement the fallback path and not also the
call into the replacement. One major factor for not requiring replacements
for getrusage()/getitimer()/setitimer() first was actually that both glibc
and musl have plans to support old kernels and need to implement
the fallback path regardless of whether we implemented the new
version or not.

       Arnd

[1] ignoring the universally hated x32 ABI

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Florian Weimer]

* Arnd Bergmann:

> On Tue, Jun 25, 2019 at 3:47 PM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Arnd Bergmann:
>>
>> > On Tue, Jun 25, 2019 at 3:29 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> >> On Tue, Jun 25, 2019 at 2:10 PM Florian Weimer <fweimer@redhat.com> wrote:
>> >>
>> >> > Does this means that RV32 will use a 32-bit struct timeval in those
>> >> > system calls?  Even if everything else 64-bit?
>> >>
>> >> Correct. Only those four (all deprecated but still used) system calls,
>> >> as we could not agree on a new interface before 5.1, and there
>> >> is no urgency for deployment when they can be emulated.
>> >
>> > Correction: getrusage() is still a recommended interface in POSIX.1-2017
>> > with no nanosecond based replacement, while wait4(), getitimer() and
>> > getrusage() are all obsolete but cannot be implemented on top of other
>> > POSIX system calls.
>>
>> This makes me rather unhappy.  I also don't see the benefit of renaming
>> all time-related system calls for new architectures.
>
> What got renamed?

futex to futex_time64 on RV32.  <asm/unistd.h> seems to expose only the
latter.

> I was trying very hard to make it as consistent
> and easy as possible. There is a strict mapping of __NR_* macros
> to argument types for each system call [1], so e.g. __kernel_timespec
> will always be used together with system calls named *time64(),
> while the old system calls always refer to the traditional
> "struct timespec {long tv_sec; long tv_nsec;}" type. This is the
> same way that loff_t gets handled, so I assumed that all C libraries
> would know how to deal with this well.

I'm afraid, but this setup makes little sense if the old system call
does not exist for an architecture.  Instead it requires additional
porting effort.

Thanks,
Florian

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Arnd Bergmann]

On Tue, Jun 25, 2019 at 4:08 PM Florian Weimer <fweimer@redhat.com> wrote:
> * Arnd Bergmann:
> > On Tue, Jun 25, 2019 at 3:47 PM Florian Weimer <fweimer@redhat.com> wrote:
> >> This makes me rather unhappy.  I also don't see the benefit of renaming
> >> all time-related system calls for new architectures.
> >
> > What got renamed?
>
> futex to futex_time64 on RV32.  <asm/unistd.h> seems to expose only the
> latter.

But that's the point: futex() takes a timespec argument based on 'long',
so that won't work beyond y2038 on 32-bit architectures and we
cannot provide that.

One of the highest priorities in the conversion was always to ensure
that new architectures would behave exactly the same way as the
existing ones, except for leaving out the compatibility support for
old C libraries that never existed on those architectures.

Reusing the old __NR_futex() macro with a new ABI would require
having architecture specific hacks even in C libraries that never
supported 32-bit time_t on any architectures, or that dropped that
support.

> > I was trying very hard to make it as consistent
> > and easy as possible. There is a strict mapping of __NR_* macros
> > to argument types for each system call [1], so e.g. __kernel_timespec
> > will always be used together with system calls named *time64(),
> > while the old system calls always refer to the traditional
> > "struct timespec {long tv_sec; long tv_nsec;}" type. This is the
> > same way that loff_t gets handled, so I assumed that all C libraries
> > would know how to deal with this well.
>
> I'm afraid, but this setup makes little sense if the old system call
> does not exist for an architecture.  Instead it requires additional
> porting effort.

I think we can still add back the time32 syscalls for rv32 in linux-5.2 if
that helps, it should be a one-line patch in the kernel (and it would
mean that linux-5.1 would be broken for anyone actually using those).

        Arnd

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Florian Weimer]

* Arnd Bergmann:

> On Tue, Jun 25, 2019 at 4:08 PM Florian Weimer <fweimer@redhat.com> wrote:
>> * Arnd Bergmann:
>> > On Tue, Jun 25, 2019 at 3:47 PM Florian Weimer <fweimer@redhat.com> wrote:
>> >> This makes me rather unhappy.  I also don't see the benefit of renaming
>> >> all time-related system calls for new architectures.
>> >
>> > What got renamed?
>>
>> futex to futex_time64 on RV32.  <asm/unistd.h> seems to expose only the
>> latter.
>
> But that's the point: futex() takes a timespec argument based on 'long',
> so that won't work beyond y2038 on 32-bit architectures and we
> cannot provide that.
>
> One of the highest priorities in the conversion was always to ensure
> that new architectures would behave exactly the same way as the
> existing ones, except for leaving out the compatibility support for
> old C libraries that never existed on those architectures.
>
> Reusing the old __NR_futex() macro with a new ABI would require
> having architecture specific hacks even in C libraries that never
> supported 32-bit time_t on any architectures, or that dropped that
> support.

I think this fails to take into account that the type differences have
clearly been abstracted away for struct timespec (you really need the
definition from an official header), and perhaps even for time_t.

If there is only a 64-bit version of those types, the syscall name
difference does not add any value whatsoever.  In glibc, I think we will
just add

#define __NR_futex __NR_futex_time64

for these architectures (only internally, we won't define SYS_futex).
And any application that wants to call the futex system call directly
will do the same thing.  Which leads to the question why the kernel
headers aren't doing it.

Thanks,
Florian

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Arnd Bergmann]

On Tue, Jun 25, 2019 at 4:29 PM Florian Weimer <fweimer@redhat.com> wrote:

>
> I think this fails to take into account that the type differences have
> clearly been abstracted away for struct timespec (you really need the
> definition from an official header), and perhaps even for time_t.
>
> If there is only a 64-bit version of those types, the syscall name
> difference does not add any value whatsoever.  In glibc, I think we will
> just add
>
> #define __NR_futex __NR_futex_time64
>
> for these architectures (only internally, we won't define SYS_futex).
> And any application that wants to call the futex system call directly
> will do the same thing.  Which leads to the question why the kernel
> headers aren't doing it.

I think it's a bad trade-off to do this hack for risc-v, and I don't
really want to encourage it.

Redefining __NR_futex for rv32 would clearly speed up the process
of the initial merge because it avoids the dependency on the general
ilp32-time64 support, but the cost would be to maintain rv32 as a
special case forever.

We already need three distinct variants of futex (and any other
time64 syscall):

a) 64-bit, timespec == __old_kernel_timespec == __kernel_timespec
futex() -> syscall(__NR_futex) -> sys_futex

b) 32-bit, timespec == __old_kernel_timespec; will stay around until ~2038
futex() -> syscall(__NR_futex) -> sys_futex

c) 32-bit, timespec == __kernel_timespec, being added now
futex() -> __futex_time64() -> syscall(__NR_futex_time64) -> sys_futex_time64

With __futex_time64() being an internal function like

int __futex_time64(...)
{
      int err = -ENOSYS;
#ifdef __NR_futex_time64
      err = syscall(__NR_futex_time64, ...);
#endif
#ifdef __NR_futex
      if (err = -ENOSYS) { /* pre-5.1 kernel */
            struct __kernel_old_timespec ts32 = ts64_to_ts32(ts);
            err = syscall(__NR_futex_time64, ... &ts32 ...);
      }
#endif
      return ret;
}

What I expected would happen here was to use the same as
case c) for rv32, while your approach would be closer to a),
with no intermediate function:

d) rv32, timespec == __kernel_timespec
futex() -> syscall(__NR_futex_time64) -> sys_futex_time64

This way you have to multiplex between time32 and time64 in
two places: existing architectures by calling __futex_time64()
instead of futex() (through whatever method you normally use
in glibc to choose between different ABI variants at link time),
while rv32 would use the old symbol but redefine the kernel
macros to do the same thing.

Is there any long-term advantage for your approach that I'm
missing?

      Arnd

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Florian Weimer]

* Arnd Bergmann:

[Exposing futex as __NR_futex for 64-bit-only-time_t]

> Is there any long-term advantage for your approach that I'm
> missing?

Userspace that calls futex and does not care about timeouts would just
work on RV32 without any porting.

For example, consider this code in glib:

| static void
| g_futex_wait (const volatile gint *address,
|               gint                 value)
| {
|   syscall (__NR_futex, address, (gsize) FUTEX_WAIT_PRIVATE, (gsize) value, NULL);
| }

This will not work on RV32 for no good reason at all.  You would
actually have to add an #ifdef for RV32 to fix it because you clearly
don't want to do this:

| static void
| g_futex_wait (const volatile gint *address,
|               gint                 value)
| {
| #ifdef __NR_futex_time64
|   syscall (__NR_futex_time64, address, (gsize) FUTEX_WAIT_PRIVATE, (gsize) value, NULL);
| #else
|   syscall (__NR_futex, address, (gsize) FUTEX_WAIT_PRIVATE, (gsize) value, NULL);
| #endif
| }

because that would break if the library was used on an older kernel
(older than the kernel headers installed at build time).

Maybe you could use this:

| static void
| g_futex_wait (const volatile gint *address,
|               gint                 value)
| {
| #ifdef __NR_futex
|   syscall (__NR_futex_time64, address, (gsize) FUTEX_WAIT_PRIVATE, (gsize) value, NULL);
| #else
|   syscall (__NR_futex_time64, address, (gsize) FUTEX_WAIT_PRIVATE, (gsize) value, NULL);
| #endif
| }

But this would still break if people actually go ahead with the removal
of the 32-bit system calls (something I think is quite impossible to do,
but some people seem to disagree).

Fallback on ENOSYS requires introducing global variable to avoid
pointless future system calls.

Thanks,
Florian

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Andreas Schwab]

On Jun 26 2019, Florian Weimer <fweimer@redhat.com> wrote:

> * Arnd Bergmann:
>
> [Exposing futex as __NR_futex for 64-bit-only-time_t]
>
>> Is there any long-term advantage for your approach that I'm
>> missing?
>
> Userspace that calls futex and does not care about timeouts would just
> work on RV32 without any porting.

Calling syscalls directly is always going to be hard to keep up-to-date,
has been fallen apart a lot already.

> But this would still break if people actually go ahead with the removal
> of the 32-bit system calls (something I think is quite impossible to do,
> but some people seem to disagree).

I'd expect that the current futex syscall will continue to work for all
its subfunctions without absolute timestamp.

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."

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Florian Weimer]

* Andreas Schwab:

>> But this would still break if people actually go ahead with the removal
>> of the 32-bit system calls (something I think is quite impossible to do,
>> but some people seem to disagree).
>
> I'd expect that the current futex syscall will continue to work for all
> its subfunctions without absolute timestamp.

I thought that RV32 just wouldn't have a futex system call at all?

Thanks,
Florian

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Andreas Schwab]

On Jul 08 2019, Florian Weimer <fweimer@redhat.com> wrote:

> * Andreas Schwab:
>
>>> But this would still break if people actually go ahead with the removal
>>> of the 32-bit system calls (something I think is quite impossible to do,
>>> but some people seem to disagree).
>>
>> I'd expect that the current futex syscall will continue to work for all
>> its subfunctions without absolute timestamp.
>
> I thought that RV32 just wouldn't have a futex system call at all?

I'm talking about legacy 32-bit architectures.

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."

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Florian Weimer]

* Andreas Schwab:

> On Jul 08 2019, Florian Weimer <fweimer@redhat.com> wrote:
>
>> * Andreas Schwab:
>>
>>>> But this would still break if people actually go ahead with the removal
>>>> of the 32-bit system calls (something I think is quite impossible to do,
>>>> but some people seem to disagree).
>>>
>>> I'd expect that the current futex syscall will continue to work for all
>>> its subfunctions without absolute timestamp.
>>
>> I thought that RV32 just wouldn't have a futex system call at all?
>
> I'm talking about legacy 32-bit architectures.

Ah.  Yes, I one would hope that.

But there has been talk of a kernel option to remove it even there, and
a suggestion that glibc would try the 64-bit time_t system call first,
to see if it is available, and prefer that.

I think this would be quite … wrong.

Thanks,
Florian

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Alistair Francis]

On Mon, Jul 8, 2019 at 5:37 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Andreas Schwab:
>
> > On Jul 08 2019, Florian Weimer <fweimer@redhat.com> wrote:
> >
> >> * Andreas Schwab:
> >>
> >>>> But this would still break if people actually go ahead with the removal
> >>>> of the 32-bit system calls (something I think is quite impossible to do,
> >>>> but some people seem to disagree).
> >>>
> >>> I'd expect that the current futex syscall will continue to work for all
> >>> its subfunctions without absolute timestamp.
> >>
> >> I thought that RV32 just wouldn't have a futex system call at all?
> >
> > I'm talking about legacy 32-bit architectures.
>
> Ah.  Yes, I one would hope that.
>
> But there has been talk of a kernel option to remove it even there, and
> a suggestion that glibc would try the 64-bit time_t system call first,
> to see if it is available, and prefer that.
>
> I think this would be quite … wrong.

So that means that the #define solution (see below) is probably the
way to go then?

#if __riscv_xlen == 32
# ifndef __NR_futex
#  define __NR_futex __NR_futex_time64
# endif
#endif

Alistair

>
> Thanks,
> Florian

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Andreas Schwab]

On Jul 09 2019, Alistair Francis <alistair23@gmail.com> wrote:

> So that means that the #define solution (see below) is probably the
> way to go then?
>
> #if __riscv_xlen == 32
> # ifndef __NR_futex
> #  define __NR_futex __NR_futex_time64
> # endif
> #endif

I don't think this is the way to go since all future 32-bit ABIs will
have to do the same.  The generic code should follow the default as
defined by <asm-generic/unistd.h>.

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."

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Alistair Francis]

On Wed, Jul 10, 2019 at 12:33 AM Andreas Schwab <schwab@suse.de> wrote:
>
> On Jul 09 2019, Alistair Francis <alistair23@gmail.com> wrote:
>
> > So that means that the #define solution (see below) is probably the
> > way to go then?
> >
> > #if __riscv_xlen == 32
> > # ifndef __NR_futex
> > #  define __NR_futex __NR_futex_time64
> > # endif
> > #endif
>
> I don't think this is the way to go since all future 32-bit ABIs will
> have to do the same.  The generic code should follow the default as
> defined by <asm-generic/unistd.h>.

I'm a little hesitant on making this change generic. This is what I'm
more thinking
 1. Add RV32 support by RV32 specific defines (see above)
 2. As other architectures move to this the RV32 fix can be either
moved to a generic include or if a different solution is decided upon
that can be used. The benefit here is that we don't end up pushing
everyone else to do what we do initially.

There will be some generic changes, we can't just #define everything
but this at least limits the generic code changes when we merge in the
RV32 port.

If everyone doesn't like this option though I'm happy to make the
changes generic.

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."

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]

On Mon, 8 Jul 2019, Florian Weimer wrote:

> > I'm talking about legacy 32-bit architectures.
> 
> Ah.  Yes, I one would hope that.
> 
> But there has been talk of a kernel option to remove it even there, and
> a suggestion that glibc would try the 64-bit time_t system call first,
> to see if it is available, and prefer that.
> 
> I think this would be quite … wrong.

glibc should generally use the 64-bit time_t system call first on legacy 
32-bit architectures (and especially in cases such as futex where there is 
a large amount of logic in glibc at a higher level in the syscall, which 
it is particularly important to avoid duplicating for different time_t 
choices), not because of systems with the 32-bit syscall removed where it 
was previously part of the kernel ABI expected by glibc (those are not 
something reasonably supportable), but to avoid duplication and code bloat 
at both the source and binary level and to have a single consistent design 
(32-bit functions wrap the corresponding 64-bit ones, in all cases where 
the function is defined in C rather than through syscalls.list) rather 
than attempting to define what is or is not a sufficiently trivial 
function implementation that duplication is not a problem.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Arnd Bergmann]

On Wed, Jun 26, 2019 at 5:48 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Arnd Bergmann:
>
> [Exposing futex as __NR_futex for 64-bit-only-time_t]


I'm realizing now that I was missing your point as I took futex as
an example assuming we would handle all 21 time64 syscalls the
same way, but you point out some issues that are specific to futex,
so I should try to separate those two things.

> > Is there any long-term advantage for your approach that I'm
> > missing?
>
> Userspace that calls futex and does not care about timeouts would just
> work on RV32 without any porting.

In general, my hope is that anything should just work on rv32 without
porting, regardless of the timeouts.

One problem specific to futex is the fact that glibc does not come with
a wrapper for it, so it's up to the applications to decide on which macro
to pass.

For most of the other syscalls, having rv32 not define the macro means
that we break applications at compile-time, and are hopefully able to
fix them in a way that works on all architectures. In case of futex,
I agree that it would be better not to break compilation when you
don't pass a timeout, but I see no good way to have it both ways.

> For example, consider this code in glib:
>
> | static void
> | g_futex_wait (const volatile gint *address,
> |               gint                 value)
> | {
> |   syscall (__NR_futex, address, (gsize) FUTEX_WAIT_PRIVATE, (gsize) value, NULL);
> | }
>
> This will not work on RV32 for no good reason at all.  You would
> actually have to add an #ifdef for RV32 to fix it because you clearly
> don't want to do this:
>
> | static void
> | g_futex_wait (const volatile gint *address,
> |               gint                 value)
> | {
> | #ifdef __NR_futex_time64
> |   syscall (__NR_futex_time64, address, (gsize) FUTEX_WAIT_PRIVATE, (gsize) value, NULL);
> | #else
> |   syscall (__NR_futex, address, (gsize) FUTEX_WAIT_PRIVATE, (gsize) value, NULL);
> | #endif
> | }
>
> because that would break if the library was used on an older kernel
> (older than the kernel headers installed at build time).

*nod*

> Maybe you could use this:
>
> | static void
> | g_futex_wait (const volatile gint *address,
> |               gint                 value)
> | {
> | #ifdef __NR_futex
> |   syscall (__NR_futex_time64, address, (gsize) FUTEX_WAIT_PRIVATE, (gsize) value, NULL);
> | #else
> |   syscall (__NR_futex_time64, address, (gsize) FUTEX_WAIT_PRIVATE, (gsize) value, NULL);
> | #endif
> | }
>
> But this would still break if people actually go ahead with the removal
> of the 32-bit system calls (something I think is quite impossible to do,
> but some people seem to disagree).
>
> Fallback on ENOSYS requires introducing global variable to avoid
> pointless future system calls.

I hope the example of g_futex_wait() becomes a little easier after
we have come up with a solution for fixing the much harder case
of using __NR_futex /with/ timeouts, such as (also from glib)

gboolean
g_cond_wait_until (GCond  *cond, GMutex *mutex, gint64  end_time)
{
 struct timespec span;
  ...
  res = syscall (__NR_futex, &cond->i[0], (gsize) FUTEX_WAIT_PRIVATE,
(gsize) sampled, &span);
 ...
}

The problem obviously is that on existing 32-bit architectures,
the first argument (__NR_futex) must correspond to the type
of the 'span' variable. Fixing this is always ugly, but has to be
done. The best I can think of is

gboolean
g_cond_wait_until (GCond  *cond, GMutex *mutex, gint64  end_time)
{
  struct timespec span;
  ...
  res = -ENOSYS;
  if (sizeof(time_t) > sizeof(__syscall_slong_t)) {
#ifdef __NR_futex_time64
     res = syscall (__NR_futex_time64, &cond->i[0], (gsize) FUTEX_WAIT_PRIVATE,
                 (gsize) sampled, &span);
#endif
 } else {
#ifdef __NR_futex
     res = syscall (__NR_futex, &cond->i[0], (gsize) FUTEX_WAIT_PRIVATE,
                 (gsize) sampled, &span);
#endif
  }
...
}

The version above will
- always use __NR_futex on 64-bit architectures and x32
- use __NR_futex on 32-bit architectures with 32-bit time_t, this will always
  work except on kernels that don't support time32 syscalls (as intended)
- use __NR_futex_time64 on 32-bit architectures with 64-bit time_t, which
  works when built with linux-5.1+ headers and running on linux-5.1+.
  This is probably good enough, as many other things are also broken
  when trying to use time64 with older kernels or headers.

One could achieve something similar by defining SYS_futex in glibc like

#if __WORDSIZE == 64 || __TIMESIZE == 32 || (defined __x86_64__ &&
defined __ILP32__)
#define SYS_futex __NR_futex
#else
#define SYS_futex __NR_futex_time64
#endif

and then requiring applications to use SYS_futex rather than __NR_futex.
Again, there would be no fallback for time64 with older kernels or
headers this way.

We can't really redefine __NR_futex in the kernel headers this way
unfortunately, because
a) there is no reliable way for kernel headers to check __TIMESIZE
    in an #ifdef (users might include asm/unistd.h before libc headers);
    the best approximation would be
  #define __NR_futex (sizeof(time_t) > sizeof(__kernel_long_t) ? \
               __NR_futex_time64 : __NR_futex_time32)
    which has a few downsides as well.
b) we need to provide both plain __NR_futex and __NR_futex_time64
    for libraries that want to call both depending on the timeout argument
    type.

        Arnd

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Florian Weimer]

* Arnd Bergmann:

> On Wed, Jun 26, 2019 at 5:48 PM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Arnd Bergmann:
>>
>> [Exposing futex as __NR_futex for 64-bit-only-time_t]
>
>
> I'm realizing now that I was missing your point as I took futex as
> an example assuming we would handle all 21 time64 syscalls the
> same way, but you point out some issues that are specific to futex,
> so I should try to separate those two things.
>
>> > Is there any long-term advantage for your approach that I'm
>> > missing?
>>
>> Userspace that calls futex and does not care about timeouts would just
>> work on RV32 without any porting.
>
> In general, my hope is that anything should just work on rv32 without
> porting, regardless of the timeouts.
>
> One problem specific to futex is the fact that glibc does not come with
> a wrapper for it, so it's up to the applications to decide on which macro
> to pass.

That's hardly special to futex.  Even if there's a perfectly fine
wrapper, some people don't want to use it.

> For most of the other syscalls, having rv32 not define the macro means
> that we break applications at compile-time, and are hopefully able to
> fix them in a way that works on all architectures. In case of futex,
> I agree that it would be better not to break compilation when you
> don't pass a timeout, but I see no good way to have it both ways.

I'm more and more confused here.

Does rv32 still have 32-bit struct timeval/struct timespec outside
getrusage?

If not, there is no risk at all that programmers confuse the types, and
no need to rename the systen calls.

If there's only a 64-bit time_t, calling futex futex_time64 makes as
much sense as alpha calling getpid getxpid.

> I hope the example of g_futex_wait() becomes a little easier after
> we have come up with a solution for fixing the much harder case
> of using __NR_futex /with/ timeouts, such as (also from glib)
>
> gboolean
> g_cond_wait_until (GCond  *cond, GMutex *mutex, gint64  end_time)
> {
>  struct timespec span;
>   ...
>   res = syscall (__NR_futex, &cond->i[0], (gsize) FUTEX_WAIT_PRIVATE,
> (gsize) sampled, &span);
>  ...
> }
>
> The problem obviously is that on existing 32-bit architectures,
> the first argument (__NR_futex) must correspond to the type
> of the 'span' variable. Fixing this is always ugly, but has to be
> done. The best I can think of is
>
> gboolean
> g_cond_wait_until (GCond  *cond, GMutex *mutex, gint64  end_time)
> {
>   struct timespec span;
>   ...
>   res = -ENOSYS;
>   if (sizeof(time_t) > sizeof(__syscall_slong_t)) {
> #ifdef __NR_futex_time64
>      res = syscall (__NR_futex_time64, &cond->i[0], (gsize) FUTEX_WAIT_PRIVATE,
>                  (gsize) sampled, &span);
> #endif
>  } else {
> #ifdef __NR_futex
>      res = syscall (__NR_futex, &cond->i[0], (gsize) FUTEX_WAIT_PRIVATE,
>                  (gsize) sampled, &span);
> #endif
>   }
> ...
> }

> The version above will
> - always use __NR_futex on 64-bit architectures and x32
> - use __NR_futex on 32-bit architectures with 32-bit time_t, this will always
>   work except on kernels that don't support time32 syscalls (as intended)
> - use __NR_futex_time64 on 32-bit architectures with 64-bit time_t, which
>   works when built with linux-5.1+ headers and running on linux-5.1+.
>   This is probably good enough, as many other things are also broken
>   when trying to use time64 with older kernels or headers.

I think the quoted fix isn't the best we can do.  Portable binaries
32-bit binaries need to call futex_time64 once to see if it is
available, and fall back to futex if it is not.  g_cond_wait_until in
particular does not have a dependency on the size of struct timespec,
but other parts of glib might, and it may not be possible to compile
glib as a while with __TIMESIZE == 64.

But t his is really an aside.  I'm concerned that porting software to
rv32 requires that applications have to deal with the time_t transition
today, and I don't see a good reason for linking the two.

Thanks,
Florian

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Andreas Schwab]

On Jun 27 2019, Florian Weimer <fweimer@redhat.com> wrote:

> But t his is really an aside.  I'm concerned that porting software to
> rv32 requires that applications have to deal with the time_t transition
> today, and I don't see a good reason for linking the two.

It's not unlike the situation with aarch64 not defining many traditional
syscalls, but only their *at variants.

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."

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Arnd Bergmann]

On Thu, Jun 27, 2019 at 9:33 AM Florian Weimer <fweimer@redhat.com> wrote:
> * Arnd Bergmann:
> > On Wed, Jun 26, 2019 at 5:48 PM Florian Weimer <fweimer@redhat.com> wrote:
> >> * Arnd Bergmann:

> > One problem specific to futex is the fact that glibc does not come with
> > a wrapper for it, so it's up to the applications to decide on which macro
> > to pass.
>
> That's hardly special to futex.  Even if there's a perfectly fine
> wrapper, some people don't want to use it.

Sure, but any application doing that is broken with when it calls into
the kernel with any mismatched types. Calling syscall(__NR_gettimeofday)
or syscall(__NR_futex) with the time64 version of timespec (from the C library)
can't work, just like calling syscall(__NR_ftruncate) with a 64-bit off_t.

Using syscall() is always going to be hard, what makes futex different
is that there is no easy way.

> > For most of the other syscalls, having rv32 not define the macro means
> > that we break applications at compile-time, and are hopefully able to
> > fix them in a way that works on all architectures. In case of futex,
> > I agree that it would be better not to break compilation when you
> > don't pass a timeout, but I see no good way to have it both ways.
>
> I'm more and more confused here.
>
> Does rv32 still have 32-bit struct timeval/struct timespec outside
> getrusage?

Only in a few drivers that we intend to fix before anyone can
use them, so no.

> If not, there is no risk at all that programmers confuse the types, and
> no need to rename the systen calls.
>
> If there's only a 64-bit time_t, calling futex futex_time64 makes as
> much sense as alpha calling getpid getxpid.

No, the rule for syscalls in the kernel is to give a new name if you
change the arguments. When we went through multiple revisions for
fadvise/fadvise64/fadvise64_64, we could have made it so that
each new architecture only has the latest version by the name of
'fadvise', but I think that would have been really confusing.

Admittedly, the ABI for timespec is messed up, since there is
no good way to get to the right argument type. We do have a
'struct timespec' definition in <linux/time.h>, and this is what one
would have to use in combination with __NR_clock_gettime or
__NR_futex, but it clearly conflicts with the definition from
the libc <time.h> when using 64-bit time_t, so you can't include
those two headers together.

I also really don't want to have a different definition of timespec
in the kernel for rv32 and get people to use that. Instead I think
anyone using the __NR_* macros should really use __kernel_timespec
and other __kernel_* types from the kernel headers in place of
the libc types in the long run. Properly cleaning up the kernel
headers is something we definitely need to do at some point
but have no specific plan for.

We have also debated adding all the __NR_*time64 macros for all
64-bit architectures, which would have been more consistent,
but so far have not done that for consistency with
llseek/stat64/fctntl64/truncate64/... that are also 32-bit only.

> > The version above will
> > - always use __NR_futex on 64-bit architectures and x32
> > - use __NR_futex on 32-bit architectures with 32-bit time_t, this will always
> >   work except on kernels that don't support time32 syscalls (as intended)
> > - use __NR_futex_time64 on 32-bit architectures with 64-bit time_t, which
> >   works when built with linux-5.1+ headers and running on linux-5.1+.
> >   This is probably good enough, as many other things are also broken
> >   when trying to use time64 with older kernels or headers.
>
> I think the quoted fix isn't the best we can do.  Portable binaries
> 32-bit binaries need to call futex_time64 once to see if it is
> available, and fall back to futex if it is not.  g_cond_wait_until in
> particular does not have a dependency on the size of struct timespec,
> but other parts of glib might, and it may not be possible to compile
> glib as a while with __TIMESIZE == 64.

Can you clarify this? Making glib work with __TIMESIZE == 64 is
clearly required anyway, and g_cond_wait_until() cannot work
unless the local timeout structure has the same type that the kernel
expects.

> But t his is really an aside.  I'm concerned that porting software to
> rv32 requires that applications have to deal with the time_t transition
> today, and I don't see a good reason for linking the two.

The risc-v kernel maintainers specifically wanted to wait for the time_t
transition with libc, in order for rv32 to avoid going through the transition
after binaries are widely distributed already.

As I said before, we could easily undo the one-line change in the kernel
and start out with the usual 32-bit off_t/time_t/... in glibc if it turns
out to be too hard to get this to work.

     Arnd

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Florian Weimer]

* Arnd Bergmann:

>> If not, there is no risk at all that programmers confuse the types, and
>> no need to rename the systen calls.
>>
>> If there's only a 64-bit time_t, calling futex futex_time64 makes as
>> much sense as alpha calling getpid getxpid.
>
> No, the rule for syscalls in the kernel is to give a new name if you
> change the arguments. When we went through multiple revisions for
> fadvise/fadvise64/fadvise64_64, we could have made it so that
> each new architecture only has the latest version by the name of
> 'fadvise', but I think that would have been really confusing.

But futex is different because in userspace, futex_time64 behaves
exactly like futex on other architectures on rv32.

> I also really don't want to have a different definition of timespec
> in the kernel for rv32 and get people to use that. Instead I think
> anyone using the __NR_* macros should really use __kernel_timespec
> and other __kernel_* types from the kernel headers in place of
> the libc types in the long run. Properly cleaning up the kernel
> headers is something we definitely need to do at some point
> but have no specific plan for.

There's only __kernel_old_timeval, no __kernel_old_timespec, so you
can't use the kernel headers to write the 32-bit fallback path.  Once we
get _TIME_BITS=64 (to change struct timespec to 64-bit, like
_FILE_OFFSET_BITS), you can't use the glibc header files either.  Not
good.

>> > The version above will
>> > - always use __NR_futex on 64-bit architectures and x32
>> > - use __NR_futex on 32-bit architectures with 32-bit time_t, this will always
>> >   work except on kernels that don't support time32 syscalls (as intended)
>> > - use __NR_futex_time64 on 32-bit architectures with 64-bit time_t, which
>> >   works when built with linux-5.1+ headers and running on linux-5.1+.
>> >   This is probably good enough, as many other things are also broken
>> >   when trying to use time64 with older kernels or headers.
>>
>> I think the quoted fix isn't the best we can do.  Portable binaries
>> 32-bit binaries need to call futex_time64 once to see if it is
>> available, and fall back to futex if it is not.  g_cond_wait_until in
>> particular does not have a dependency on the size of struct timespec,
>> but other parts of glib might, and it may not be possible to compile
>> glib as a while with __TIMESIZE == 64.
>
> Can you clarify this? Making glib work with __TIMESIZE == 64 is
> clearly required anyway,

I'm not sure.  glib could deprecate all the APIs that use time_t
externally.  Given that they don't want to bump ABI, they may not want
to compile with __TIMESIZE == 64 on old 32-bit systems.

> and g_cond_wait_until() cannot work unless the local timeout structure
> has the same type that the kernel expects.

True, and that code is currently really, really hard to write (for
legacy 32-bit architectures).  For new 32-bit architectures, there is
just pointless source code difference without any added value in terms
of type safety.

>> But t his is really an aside.  I'm concerned that porting software to
>> rv32 requires that applications have to deal with the time_t transition
>> today, and I don't see a good reason for linking the two.
>
> The risc-v kernel maintainers specifically wanted to wait for the
> time_t transition with libc, in order for rv32 to avoid going through
> the transition after binaries are widely distributed already.

That's a different concern.  They didn't want a 32-bit-time_t ABI.  I
expect that they might have chosen differently if they realized that
they'd need to absorb the userspace 64-bit porting cost, just to get
rv32 going.

> As I said before, we could easily undo the one-line change in the
> kernel and start out with the usual 32-bit off_t/time_t/... in glibc
> if it turns out to be too hard to get this to work.

glibc isn't the problem.  It's source-level changes to applications
which use kernel headers.

Thanks,
Florian

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Arnd Bergmann]

On Thu, Jun 27, 2019 at 1:12 PM Florian Weimer <fweimer@redhat.com> wrote:
> * Arnd Bergmann:
> >> If not, there is no risk at all that programmers confuse the types, and
> >> no need to rename the systen calls.
> >>
> >> If there's only a 64-bit time_t, calling futex futex_time64 makes as
> >> much sense as alpha calling getpid getxpid.
> >
> > No, the rule for syscalls in the kernel is to give a new name if you
> > change the arguments. When we went through multiple revisions for
> > fadvise/fadvise64/fadvise64_64, we could have made it so that
> > each new architecture only has the latest version by the name of
> > 'fadvise', but I think that would have been really confusing.
>
> But futex is different because in userspace, futex_time64 behaves
> exactly like futex on other architectures on rv32.

Only as long as nobody tries to define their own __timespec structure to
pass into futex, based on the traditional definition. Given the lack
or a correct way to get to the definition, that would not be an
unreasonable thing to do for getting it to work on arm32
as a fallback.

> > I also really don't want to have a different definition of timespec
> > in the kernel for rv32 and get people to use that. Instead I think
> > anyone using the __NR_* macros should really use __kernel_timespec
> > and other __kernel_* types from the kernel headers in place of
> > the libc types in the long run. Properly cleaning up the kernel
> > headers is something we definitely need to do at some point
> > but have no specific plan for.
>
> There's only __kernel_old_timeval, no __kernel_old_timespec, so you
> can't use the kernel headers to write the 32-bit fallback path.  Once we
> get _TIME_BITS=64 (to change struct timespec to 64-bit, like
> _FILE_OFFSET_BITS), you can't use the glibc header files either.  Not
> good.

Right, that is clearly part of the cleanup that needs to happen.
I thought we had actually merged the __kernel_old_timespec
patch at some point, but evidently we have not.

> >> I think the quoted fix isn't the best we can do.  Portable binaries
> >> 32-bit binaries need to call futex_time64 once to see if it is
> >> available, and fall back to futex if it is not.  g_cond_wait_until in
> >> particular does not have a dependency on the size of struct timespec,
> >> but other parts of glib might, and it may not be possible to compile
> >> glib as a while with __TIMESIZE == 64.
> >
> > Can you clarify this? Making glib work with __TIMESIZE == 64 is
> > clearly required anyway,
>
> I'm not sure.  glib could deprecate all the APIs that use time_t
> externally.  Given that they don't want to bump ABI, they may not want
> to compile with __TIMESIZE == 64 on old 32-bit systems.

From a very brief look at glib, my impression is that this is again a
rather special case: all the external interfaces in glib are already
independent of sizeof(time_t), and internally it should be time64
safe already when built against a C library with 64-bit time_t
(all internal types use 64-bit seconds), except for the futex usage
usage in g_cond_wait_until().

[glib has a different problem with its deprecated GTimeVal type
 that they will have to solve to actually run beyond 2038, but
 let's not get into that]

Many other libraries do have external interfaces based on time_t,
and have to deal with those breaking between different values
of _TIME_BITS. I suspect the only realistic way to deal with this
on a large scale is to do a full distro rebuild with _TIME_BITS=64
and then fix whatever broke, but not expect a solution at the ABI
level like glibc is doing to support both versions in one binary.

> >> But t his is really an aside.  I'm concerned that porting software to
> >> rv32 requires that applications have to deal with the time_t transition
> >> today, and I don't see a good reason for linking the two.
> >
> > The risc-v kernel maintainers specifically wanted to wait for the
> > time_t transition with libc, in order for rv32 to avoid going through
> > the transition after binaries are widely distributed already.
>
> That's a different concern.  They didn't want a 32-bit-time_t ABI.  I
> expect that they might have chosen differently if they realized that
> they'd need to absorb the userspace 64-bit porting cost, just to get
> rv32 going.

I warned them that this would be extra work, but I also hope that
we will help each other while bringing up time64 distro support
on rv32, arm32 and other 32-bit architectures.

> > As I said before, we could easily undo the one-line change in the
> > kernel and start out with the usual 32-bit off_t/time_t/... in glibc
> > if it turns out to be too hard to get this to work.
>
> glibc isn't the problem.  It's source-level changes to applications
> which use kernel headers.

Right, I should have not pointed to glibc in particular. The problem
is really anything in user space that makes assumptions about
time_t and how it relates to other types and interfaces.

Applications using __NR_futex (and I hope less commonly the
other time64 syscalls) need to be fixed for arm32, and I hope
to get some help on this if the rv32 developers get there first.

Another example that is independent of the kernel is apparently
the Python C extension API, which fundamentally assumes that
'time_t' is the same as 'long'. If we first address this on arm32,
this will help rv32 as well.

      Arnd

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Alistair Francis]

On Thu, Jun 27, 2019 at 8:24 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Jun 27, 2019 at 1:12 PM Florian Weimer <fweimer@redhat.com> wrote:
> > * Arnd Bergmann:
> > >> If not, there is no risk at all that programmers confuse the types, and
> > >> no need to rename the systen calls.
> > >>
> > >> If there's only a 64-bit time_t, calling futex futex_time64 makes as
> > >> much sense as alpha calling getpid getxpid.
> > >
> > > No, the rule for syscalls in the kernel is to give a new name if you
> > > change the arguments. When we went through multiple revisions for
> > > fadvise/fadvise64/fadvise64_64, we could have made it so that
> > > each new architecture only has the latest version by the name of
> > > 'fadvise', but I think that would have been really confusing.
> >
> > But futex is different because in userspace, futex_time64 behaves
> > exactly like futex on other architectures on rv32.
>
> Only as long as nobody tries to define their own __timespec structure to
> pass into futex, based on the traditional definition. Given the lack
> or a correct way to get to the definition, that would not be an
> unreasonable thing to do for getting it to work on arm32
> as a fallback.

I'm unclear what the decision here is. I currently have a patch that does this:

+#if __riscv_xlen == 32
+/* Define the __NR_futex as __NR_futex64 as RV32 doesn't have a
+ * __NR_futex syscall.
+ */
+# ifndef __NR_futex
+#  define __NR_futex __NR_futex_time64
+# endif
+#endif

for futex and other missing syscalls in my RV32 port. It seems to be
working fine for RV32 (limited testing only).

What is the consensus here? I would like to try and tidy up the patch
set next week so that others can use this for RV32 until the glibc
merge window opens again.

Alistair

>
> > > I also really don't want to have a different definition of timespec
> > > in the kernel for rv32 and get people to use that. Instead I think
> > > anyone using the __NR_* macros should really use __kernel_timespec
> > > and other __kernel_* types from the kernel headers in place of
> > > the libc types in the long run. Properly cleaning up the kernel
> > > headers is something we definitely need to do at some point
> > > but have no specific plan for.
> >
> > There's only __kernel_old_timeval, no __kernel_old_timespec, so you
> > can't use the kernel headers to write the 32-bit fallback path.  Once we
> > get _TIME_BITS=64 (to change struct timespec to 64-bit, like
> > _FILE_OFFSET_BITS), you can't use the glibc header files either.  Not
> > good.
>
> Right, that is clearly part of the cleanup that needs to happen.
> I thought we had actually merged the __kernel_old_timespec
> patch at some point, but evidently we have not.
>
> > >> I think the quoted fix isn't the best we can do.  Portable binaries
> > >> 32-bit binaries need to call futex_time64 once to see if it is
> > >> available, and fall back to futex if it is not.  g_cond_wait_until in
> > >> particular does not have a dependency on the size of struct timespec,
> > >> but other parts of glib might, and it may not be possible to compile
> > >> glib as a while with __TIMESIZE == 64.
> > >
> > > Can you clarify this? Making glib work with __TIMESIZE == 64 is
> > > clearly required anyway,
> >
> > I'm not sure.  glib could deprecate all the APIs that use time_t
> > externally.  Given that they don't want to bump ABI, they may not want
> > to compile with __TIMESIZE == 64 on old 32-bit systems.
>
> From a very brief look at glib, my impression is that this is again a
> rather special case: all the external interfaces in glib are already
> independent of sizeof(time_t), and internally it should be time64
> safe already when built against a C library with 64-bit time_t
> (all internal types use 64-bit seconds), except for the futex usage
> usage in g_cond_wait_until().
>
> [glib has a different problem with its deprecated GTimeVal type
>  that they will have to solve to actually run beyond 2038, but
>  let's not get into that]
>
> Many other libraries do have external interfaces based on time_t,
> and have to deal with those breaking between different values
> of _TIME_BITS. I suspect the only realistic way to deal with this
> on a large scale is to do a full distro rebuild with _TIME_BITS=64
> and then fix whatever broke, but not expect a solution at the ABI
> level like glibc is doing to support both versions in one binary.
>
> > >> But t his is really an aside.  I'm concerned that porting software to
> > >> rv32 requires that applications have to deal with the time_t transition
> > >> today, and I don't see a good reason for linking the two.
> > >
> > > The risc-v kernel maintainers specifically wanted to wait for the
> > > time_t transition with libc, in order for rv32 to avoid going through
> > > the transition after binaries are widely distributed already.
> >
> > That's a different concern.  They didn't want a 32-bit-time_t ABI.  I
> > expect that they might have chosen differently if they realized that
> > they'd need to absorb the userspace 64-bit porting cost, just to get
> > rv32 going.
>
> I warned them that this would be extra work, but I also hope that
> we will help each other while bringing up time64 distro support
> on rv32, arm32 and other 32-bit architectures.
>
> > > As I said before, we could easily undo the one-line change in the
> > > kernel and start out with the usual 32-bit off_t/time_t/... in glibc
> > > if it turns out to be too hard to get this to work.
> >
> > glibc isn't the problem.  It's source-level changes to applications
> > which use kernel headers.
>
> Right, I should have not pointed to glibc in particular. The problem
> is really anything in user space that makes assumptions about
> time_t and how it relates to other types and interfaces.
>
> Applications using __NR_futex (and I hope less commonly the
> other time64 syscalls) need to be fixed for arm32, and I hope
> to get some help on this if the rv32 developers get there first.
>
> Another example that is independent of the kernel is apparently
> the Python C extension API, which fundamentally assumes that
> 'time_t' is the same as 'long'. If we first address this on arm32,
> this will help rv32 as well.
>
>       Arnd

Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Alistair Francis]

On Tue, Jun 25, 2019 at 5:01 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Jun 25, 2019 at 1:07 PM Florian Weimer <fweimer@redhat.com> wrote:
> >
> > * Zack Weinberg:
> >
> > > On Mon, Jun 24, 2019 at 8:12 PM Alistair Francis
> > > <alistair.francis@wdc.com> wrote:
> > >>
> > >> If the waitid syscall is avaliable let's use that as waitpid
> > >> and wait4 aren't always avaliable (they aren't avaliable on RV32).
> > >
> > > wait4 does something that can't be done any other way (retrieve
> > > resource usage information), RV32 should have it.
> >
> > I think the problem is that the kernel provides wait4 under a different
> > name because struct rusage has two fields of struct timeval.
> >
> > I think this needs to be covered by the syscall renaming mechanism, to
> > get a working wait4, and not changes to wait.
>
> The kernel system call waitid() is a superset of glibc's wait4() and
> waitid(), it has an extra rusage argument.
>
> Originally, my plan was to replace kernel's waitid() with
> a waitid_time64() that takes an updated rusage structure,
> but that never happened.
>
> I still left wait4() commented out since it should not be
> needed when the kernel has waitid(). I have an implementation
> of wait4() based on waitid() that I did for musl and tested
> successfully with ltp, see [1].
> Unless I did something very wrong there, you should be able
> to use something like this in glibc.

Thanks for that, I still see hangs though when I port that to glibc.

Alistair

>
> Similar coversions of timeval have to be done in getrusage(),
> getitimer() and setitimer(), all of which expect a 32-bit
> timeval couting elapsed time (so no overflow in y2038).
> These need to be converted to the 64-bit timeval in the
> public glibc interface.
>
>        Arnd
>
> [1] https://git.linaro.org/people/arnd/musl-y2038.git/tree/src/linux/wait4.c

[RFC v2 09/20] sysdeps/getrlimit: Use prlimit64 if avaliable

[Alistair Francis]

If the prlimit64 syscall is avaliable let's use that instead of
ugetrlimit as it isn't always avaliable (they aren't avaliable
on RV32).

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
 ChangeLog                           | 1 +
 sysdeps/unix/sysv/linux/getrlimit.c | 9 +++++++++
 2 files changed, 10 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 9ed9bea8b1..1f1070ebc3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -8,6 +8,7 @@
 	* sysdeps/unix/sysv/linux/wait.c: Use __NR_waitid if avaliable.
 	* sysdeps/unix/sysv/linux/waitpid.c: Likewise.
 	* sysdeps/unix/sysv/linux/waitpid_nocancel.c: Likewise.
+	* sysdeps/unix/sysv/linux/getrlimit.c: Use __NR_prlimit64 if avaliable
 
 2019-06-20  Dmitry V. Levin  <ldv@altlinux.org>
 	    Florian Weimer  <fweimer@redhat.com>
diff --git a/sysdeps/unix/sysv/linux/getrlimit.c b/sysdeps/unix/sysv/linux/getrlimit.c
index 10c0176619..741b065b25 100644
--- a/sysdeps/unix/sysv/linux/getrlimit.c
+++ b/sysdeps/unix/sysv/linux/getrlimit.c
@@ -35,7 +35,16 @@
 int
 __new_getrlimit (enum __rlimit_resource resource, struct rlimit *rlim)
 {
+#ifdef __ASSUME_RLIM64_SYSCALLS
+  return INLINE_SYSCALL_CALL (prlimit64, 0, resource, rlim, NULL);
+#else
+# ifdef __NR_prlimit64
+  long int ret = INLINE_SYSCALL_CALL (prlimit64, 0, resource, rlim, NULL);
+  if (ret == 0 || errno != ENOSYS)
+    return ret;
+# endif
   return INLINE_SYSCALL_CALL (ugetrlimit, resource, rlim);
+#endif
 }
 weak_alias (__new_getrlimit, __getrlimit)
 hidden_weak (__getrlimit)
-- 
2.22.0

Re: [RFC v2 09/20] sysdeps/getrlimit: Use prlimit64 if avaliable

[Florian Weimer]

* Alistair Francis:

> If the prlimit64 syscall is avaliable let's use that instead of
> ugetrlimit as it isn't always avaliable (they aren't avaliable
> on RV32).

> diff --git a/sysdeps/unix/sysv/linux/getrlimit.c b/sysdeps/unix/sysv/linux/getrlimit.c
> index 10c0176619..741b065b25 100644
> --- a/sysdeps/unix/sysv/linux/getrlimit.c
> +++ b/sysdeps/unix/sysv/linux/getrlimit.c
> @@ -35,7 +35,16 @@
>  int
>  __new_getrlimit (enum __rlimit_resource resource, struct rlimit *rlim)
>  {
> +#ifdef __ASSUME_RLIM64_SYSCALLS
> +  return INLINE_SYSCALL_CALL (prlimit64, 0, resource, rlim, NULL);
> +#else
> +# ifdef __NR_prlimit64
> +  long int ret = INLINE_SYSCALL_CALL (prlimit64, 0, resource, rlim, NULL);
> +  if (ret == 0 || errno != ENOSYS)
> +    return ret;
> +# endif
>    return INLINE_SYSCALL_CALL (ugetrlimit, resource, rlim);
> +#endif

I think that's not correct because with this change, defining
__ASSUME_RLIM64_SYSCALLS changes the struct expected by getrlimit.
I believe the expectation is that such definitions only alter the set of
system calls glibc assumes to be present.  They should not affect the
external glibc ABI exposed on its function call interface.

Thanks,
Florian

Re: [RFC v2 09/20] sysdeps/getrlimit: Use prlimit64 if avaliable

[Alistair Francis]

On Tue, Jun 25, 2019 at 4:11 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Alistair Francis:
>
> > If the prlimit64 syscall is avaliable let's use that instead of
> > ugetrlimit as it isn't always avaliable (they aren't avaliable
> > on RV32).
>
> > diff --git a/sysdeps/unix/sysv/linux/getrlimit.c b/sysdeps/unix/sysv/linux/getrlimit.c
> > index 10c0176619..741b065b25 100644
> > --- a/sysdeps/unix/sysv/linux/getrlimit.c
> > +++ b/sysdeps/unix/sysv/linux/getrlimit.c
> > @@ -35,7 +35,16 @@
> >  int
> >  __new_getrlimit (enum __rlimit_resource resource, struct rlimit *rlim)
> >  {
> > +#ifdef __ASSUME_RLIM64_SYSCALLS
> > +  return INLINE_SYSCALL_CALL (prlimit64, 0, resource, rlim, NULL);
> > +#else
> > +# ifdef __NR_prlimit64
> > +  long int ret = INLINE_SYSCALL_CALL (prlimit64, 0, resource, rlim, NULL);
> > +  if (ret == 0 || errno != ENOSYS)
> > +    return ret;
> > +# endif
> >    return INLINE_SYSCALL_CALL (ugetrlimit, resource, rlim);
> > +#endif
>
> I think that's not correct because with this change, defining
> __ASSUME_RLIM64_SYSCALLS changes the struct expected by getrlimit.

I'm not clear what you mean here, why is the struct expected by
getrlimit different?

> I believe the expectation is that such definitions only alter the set of
> system calls glibc assumes to be present.  They should not affect the
> external glibc ABI exposed on its function call interface.

I agree, I don't see how this changes the function call interface though.

Alistair

>
> Thanks,
> Florian

Re: [RFC v2 09/20] sysdeps/getrlimit: Use prlimit64 if avaliable

[Florian Weimer]

* Alistair Francis:

> On Tue, Jun 25, 2019 at 4:11 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Alistair Francis:
>>
>> > If the prlimit64 syscall is avaliable let's use that instead of
>> > ugetrlimit as it isn't always avaliable (they aren't avaliable
>> > on RV32).
>>
>> > diff --git a/sysdeps/unix/sysv/linux/getrlimit.c b/sysdeps/unix/sysv/linux/getrlimit.c
>> > index 10c0176619..741b065b25 100644
>> > --- a/sysdeps/unix/sysv/linux/getrlimit.c
>> > +++ b/sysdeps/unix/sysv/linux/getrlimit.c
>> > @@ -35,7 +35,16 @@
>> >  int
>> >  __new_getrlimit (enum __rlimit_resource resource, struct rlimit *rlim)
>> >  {
>> > +#ifdef __ASSUME_RLIM64_SYSCALLS
>> > +  return INLINE_SYSCALL_CALL (prlimit64, 0, resource, rlim, NULL);
>> > +#else
>> > +# ifdef __NR_prlimit64
>> > +  long int ret = INLINE_SYSCALL_CALL (prlimit64, 0, resource, rlim, NULL);
>> > +  if (ret == 0 || errno != ENOSYS)
>> > +    return ret;
>> > +# endif
>> >    return INLINE_SYSCALL_CALL (ugetrlimit, resource, rlim);
>> > +#endif
>>
>> I think that's not correct because with this change, defining
>> __ASSUME_RLIM64_SYSCALLS changes the struct expected by getrlimit.
>
> I'm not clear what you mean here, why is the struct expected by
> getrlimit different?

On current 32-bit architectures, ugetrlimit expects a 32-bit rlim_t
type.  But prlimit64 assumes a 64-bit rlim_t type.  Maybe this goes
wrong in either case, just by the existence of the prlimit64 system call
number, whether or not __ASSUME_RLIM64_SYSCALLS is defined.

But maybe I'm missing something?

Thanks,
Florian

Re: [RFC v2 09/20] sysdeps/getrlimit: Use prlimit64 if avaliable

[Alistair Francis]

On Tue, Jun 25, 2019 at 2:10 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Alistair Francis:
>
> > On Tue, Jun 25, 2019 at 4:11 AM Florian Weimer <fweimer@redhat.com> wrote:
> >>
> >> * Alistair Francis:
> >>
> >> > If the prlimit64 syscall is avaliable let's use that instead of
> >> > ugetrlimit as it isn't always avaliable (they aren't avaliable
> >> > on RV32).
> >>
> >> > diff --git a/sysdeps/unix/sysv/linux/getrlimit.c b/sysdeps/unix/sysv/linux/getrlimit.c
> >> > index 10c0176619..741b065b25 100644
> >> > --- a/sysdeps/unix/sysv/linux/getrlimit.c
> >> > +++ b/sysdeps/unix/sysv/linux/getrlimit.c
> >> > @@ -35,7 +35,16 @@
> >> >  int
> >> >  __new_getrlimit (enum __rlimit_resource resource, struct rlimit *rlim)
> >> >  {
> >> > +#ifdef __ASSUME_RLIM64_SYSCALLS
> >> > +  return INLINE_SYSCALL_CALL (prlimit64, 0, resource, rlim, NULL);
> >> > +#else
> >> > +# ifdef __NR_prlimit64
> >> > +  long int ret = INLINE_SYSCALL_CALL (prlimit64, 0, resource, rlim, NULL);
> >> > +  if (ret == 0 || errno != ENOSYS)
> >> > +    return ret;
> >> > +# endif
> >> >    return INLINE_SYSCALL_CALL (ugetrlimit, resource, rlim);
> >> > +#endif
> >>
> >> I think that's not correct because with this change, defining
> >> __ASSUME_RLIM64_SYSCALLS changes the struct expected by getrlimit.
> >
> > I'm not clear what you mean here, why is the struct expected by
> > getrlimit different?
>
> On current 32-bit architectures, ugetrlimit expects a 32-bit rlim_t
> type.  But prlimit64 assumes a 64-bit rlim_t type.  Maybe this goes
> wrong in either case, just by the existence of the prlimit64 system call
> number, whether or not __ASSUME_RLIM64_SYSCALLS is defined.

Ah, I see what you mean now. Yes they do end up being different rlimit structs.

I also just realised that I don't need this patch, as
__RLIM_T_MATCHES_RLIM64_T is now defined, I'm going to drop this
patch.


Alistair

>
> But maybe I'm missing something?
>
> Thanks,
> Florian

[RFC v2 10/20] Documentation for the RISC-V 32-bit port

[Alistair Francis]

From: Zong Li <zongbox@gmail.com>

There are RISC-V 64-bit port information in these documentations. I add
the small documentation entries about the RISC-V 32-bit port together.
---
 NEWS   | 6 ++++++
 README | 1 +
 2 files changed, 7 insertions(+)

diff --git a/NEWS b/NEWS
index 8a2fecef47..15a314a6fc 100644
--- a/NEWS
+++ b/NEWS
@@ -152,6 +152,12 @@ Major new features:
   "%EY" to control how the year number is formatted; they have the
   same effect that they would on "%Ey".
 
+* Support RISC-V port for 32-bit. The ISA and ABI pairs supported as follows:
+
+    - rv32imac ilp32
+    - rv32imafdc ilp32
+    - rv32imafdc ilp32d
+
 Deprecated and removed features, and other changes affecting compatibility:
 
 * The glibc.tune tunable namespace has been renamed to glibc.cpu and the
diff --git a/README b/README
index eb9b0b34a3..2dc80d0062 100644
--- a/README
+++ b/README
@@ -38,6 +38,7 @@ The GNU C Library supports these configurations for using Linux kernels:
 	powerpc64*-*-linux-gnu	Big-endian and little-endian.
 	s390-*-linux-gnu
 	s390x-*-linux-gnu
+	riscv32-*-linux-gnu
 	riscv64-*-linux-gnu
 	sh[34]-*-linux-gnu
 	sparc*-*-linux-gnu
-- 
2.22.0

[RFC v2 11/20] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64

[Alistair Francis]

Using the original glibc headers under bits/ let's make small
modifications to use 64-bit time_t and off_t for both RV32 and RV64.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
 ChangeLog                                     |  4 +
 .../unix/sysv/linux/riscv/bits/environments.h | 85 ++++++++++++++++++
 sysdeps/unix/sysv/linux/riscv/bits/time64.h   | 36 ++++++++
 sysdeps/unix/sysv/linux/riscv/bits/timesize.h | 22 +++++
 .../unix/sysv/linux/riscv/bits/typesizes.h    | 89 +++++++++++++++++++
 5 files changed, 236 insertions(+)
 create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/environments.h
 create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/time64.h
 create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/timesize.h
 create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/typesizes.h

diff --git a/ChangeLog b/ChangeLog
index 1f1070ebc3..9854fb6df7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -9,6 +9,10 @@
 	* sysdeps/unix/sysv/linux/waitpid.c: Likewise.
 	* sysdeps/unix/sysv/linux/waitpid_nocancel.c: Likewise.
 	* sysdeps/unix/sysv/linux/getrlimit.c: Use __NR_prlimit64 if avaliable
+	* sysdeps/unix/sysv/linux/riscv/bits/environments.h: Use 64-bit time_t and off_t for RV32 and RV64.
+	* sysdeps/unix/sysv/linux/riscv/bits/time64.h: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/bits/timesize.h: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/bits/typesizes.h: Likewise.
 
 2019-06-20  Dmitry V. Levin  <ldv@altlinux.org>
 	    Florian Weimer  <fweimer@redhat.com>
diff --git a/sysdeps/unix/sysv/linux/riscv/bits/environments.h b/sysdeps/unix/sysv/linux/riscv/bits/environments.h
new file mode 100644
index 0000000000..bdbf18fca0
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/bits/environments.h
@@ -0,0 +1,85 @@
+/* Copyright (C) 1999-2019 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <http://www.gnu.org/licenses/>.  */
+
+#ifndef _UNISTD_H
+# error "Never include this file directly.  Use <unistd.h> instead"
+#endif
+
+#include <bits/wordsize.h>
+
+/* This header should define the following symbols under the described
+   situations.  A value `1' means that the model is always supported,
+   `-1' means it is never supported.  Undefined means it cannot be
+   statically decided.
+
+   _POSIX_V7_ILP32_OFF32   32bit int, long, pointers, and off_t type
+   _POSIX_V7_ILP32_OFFBIG  32bit int, long, and pointers and larger off_t type
+
+   _POSIX_V7_LP64_OFF32	   64bit long and pointers and 32bit off_t type
+   _POSIX_V7_LPBIG_OFFBIG  64bit long and pointers and large off_t type
+
+   The macros _POSIX_V6_ILP32_OFF32, _POSIX_V6_ILP32_OFFBIG,
+   _POSIX_V6_LP64_OFF32, _POSIX_V6_LPBIG_OFFBIG, _XBS5_ILP32_OFF32,
+   _XBS5_ILP32_OFFBIG, _XBS5_LP64_OFF32, and _XBS5_LPBIG_OFFBIG were
+   used in previous versions of the Unix standard and are available
+   only for compatibility.
+*/
+
+#if __WORDSIZE == 64
+
+/* We can never provide environments with 32-bit wide pointers.  */
+# define _POSIX_V7_ILP32_OFF32	-1
+# define _POSIX_V7_ILP32_OFFBIG	-1
+# define _POSIX_V6_ILP32_OFF32	-1
+# define _POSIX_V6_ILP32_OFFBIG	-1
+# define _XBS5_ILP32_OFF32	-1
+# define _XBS5_ILP32_OFFBIG	-1
+/* We also have no use (for now) for an environment with bigger pointers
+   and offsets.  */
+# define _POSIX_V7_LPBIG_OFFBIG	-1
+# define _POSIX_V6_LPBIG_OFFBIG	-1
+# define _XBS5_LPBIG_OFFBIG	-1
+
+/* By default we have 64-bit wide `long int', pointers and `off_t'.  */
+# define _POSIX_V7_LP64_OFF64	1
+# define _POSIX_V6_LP64_OFF64	1
+# define _XBS5_LP64_OFF64	1
+
+#else /* __WORDSIZE == 32 */
+
+/* RISC-V requires 64-bit off_t
+  # undef _POSIX_V7_ILP32_OFF32
+  # undef _POSIX_V6_ILP32_OFF32
+  # undef _XBS5_ILP32_OFF32
+ */
+
+# define _POSIX_V7_ILP32_OFFBIG  1
+# define _POSIX_V6_ILP32_OFFBIG  1
+# define _XBS5_ILP32_OFFBIG   1
+
+/* We can never provide environments with 64-bit wide pointers.  */
+# define _POSIX_V7_LP64_OFF64	-1
+# define _POSIX_V7_LPBIG_OFFBIG	-1
+# define _POSIX_V6_LP64_OFF64	-1
+# define _POSIX_V6_LPBIG_OFFBIG	-1
+# define _XBS5_LP64_OFF64	-1
+# define _XBS5_LPBIG_OFFBIG	-1
+
+/* CFLAGS.  */
+#define __ILP32_OFFBIG_CFLAGS   "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
+
+#endif /* __WORDSIZE == 32 */
diff --git a/sysdeps/unix/sysv/linux/riscv/bits/time64.h b/sysdeps/unix/sysv/linux/riscv/bits/time64.h
new file mode 100644
index 0000000000..4be26d32d4
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/bits/time64.h
@@ -0,0 +1,36 @@
+/* bits/time64.h -- underlying types for __time64_t.  Generic version.
+   Copyright (C) 2018-2019 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <http://www.gnu.org/licenses/>.  */
+
+#ifndef _BITS_TYPES_H
+# error "Never include <bits/time64.h> directly; use <sys/types.h> instead."
+#endif
+
+#ifndef	_BITS_TIME64_H
+#define	_BITS_TIME64_H	1
+
+/* Define __TIME64_T_TYPE so that it is always a 64-bit type.  */
+
+#if __WORDSIZE == 64
+/* If we already have 64-bit time type then use it.  */
+# define __TIME64_T_TYPE		__TIME_T_TYPE
+#else
+/* Define a 64-bit time type alongsize the 32-bit one.  */
+# define __TIME64_T_TYPE		__SQUAD_TYPE
+#endif
+
+#endif /* bits/time64.h */
diff --git a/sysdeps/unix/sysv/linux/riscv/bits/timesize.h b/sysdeps/unix/sysv/linux/riscv/bits/timesize.h
new file mode 100644
index 0000000000..150af80f86
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/bits/timesize.h
@@ -0,0 +1,22 @@
+/* Bit size of the time_t type at glibc build time, general case.
+   Copyright (C) 2018-2019 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <http://www.gnu.org/licenses/>.  */
+
+#include <bits/wordsize.h>
+
+/* RV32 and RV64 both use 64-bit time_t */
+#define __TIMESIZE	64
diff --git a/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
new file mode 100644
index 0000000000..3e7c8e70aa
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
@@ -0,0 +1,89 @@
+/* bits/typesizes.h -- underlying types for *_t.  Generic version.
+   Copyright (C) 2002-2019 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <http://www.gnu.org/licenses/>.  */
+
+#ifndef _BITS_TYPES_H
+# error "Never include <bits/typesizes.h> directly; use <sys/types.h> instead."
+#endif
+
+#ifndef	_BITS_TYPESIZES_H
+#define	_BITS_TYPESIZES_H	1
+
+/* See <bits/types.h> for the meaning of these macros.  This file exists so
+   that <bits/types.h> need not vary across different GNU platforms.  */
+
+
+
+#define __DEV_T_TYPE    __UQUAD_TYPE
+#define __UID_T_TYPE    __U32_TYPE
+#define __GID_T_TYPE    __U32_TYPE
+#define __INO_T_TYPE    __UQUAD_TYPE
+#define __INO64_T_TYPE     __UQUAD_TYPE
+#define __MODE_T_TYPE      __U32_TYPE
+#define __NLINK_T_TYPE    __UQUAD_TYPE
+
+#define __OFF_T_TYPE    __SQUAD_TYPE
+#define __OFF64_T_TYPE     __SQUAD_TYPE
+#define __PID_T_TYPE    __S32_TYPE
+#define __RLIM_T_TYPE      __UQUAD_TYPE
+#define __RLIM64_T_TYPE    __UQUAD_TYPE
+#define __BLKCNT_T_TYPE    __SQUAD_TYPE
+#define __BLKCNT64_T_TYPE  __SQUAD_TYPE
+#define __FSBLKCNT_T_TYPE  __UQUAD_TYPE
+#define __FSBLKCNT64_T_TYPE   __UQUAD_TYPE
+#define __FSFILCNT_T_TYPE  __UQUAD_TYPE
+#define __FSFILCNT64_T_TYPE   __UQUAD_TYPE
+#define __FSWORD_T_TYPE   __SQUAD_TYPE
+
+#define __ID_T_TYPE     __U32_TYPE
+#define __CLOCK_T_TYPE     __SQUAD_TYPE
+#define __TIME_T_TYPE      __SQUAD_TYPE
+#define __USECONDS_T_TYPE  __U32_TYPE
+#define __SUSECONDS_T_TYPE __SQUAD_TYPE
+#define __DADDR_T_TYPE     __S32_TYPE
+#define __KEY_T_TYPE    __S32_TYPE
+#define __CLOCKID_T_TYPE   __S32_TYPE
+#define __TIMER_T_TYPE     void *
+#define __BLKSIZE_T_TYPE   __SQUAD_TYPE
+#define __FSID_T_TYPE      struct { int __val[2]; }
+#define __SSIZE_T_TYPE     __SWORD_TYPE
+#define __SYSCALL_SLONG_TYPE __SQUAD_TYPE
+#define __SYSCALL_ULONG_TYPE __UQUAD_TYPE
+#define __CPU_MASK_TYPE    __UQUAD_TYPE
+
+/* Tell the libc code that off_t and off64_t are actually the same type
+   for all ABI purposes, even if possibly expressed as different base types
+   for C type-checking purposes.  */
+# define __OFF_T_MATCHES_OFF64_T 1
+
+/* Same for ino_t and ino64_t.  */
+# define __INO_T_MATCHES_INO64_T 1
+
+/* And for rlim_t and rlim64_t.  */
+# define __RLIM_T_MATCHES_RLIM64_T  1
+
+/* Define these as RV32 requires 64-bit syscall and RV64 will happily
+ * use them.
+ */
+#define __ASSUME_TIME64_SYSCALLS 1
+#define __ASSUME_RLIM64_SYSCALLS 1
+
+/* Number of descriptors that can fit in an `fd_set'.  */
+#define	__FD_SETSIZE		1024
+
+
+#endif /* bits/typesizes.h */
-- 
2.22.0

[RFC v2 12/20] RISC-V: Support dynamic loader for the 32-bit

[Alistair Francis]

From: Zong Li <zongbox@gmail.com>

Add the LD_SO_ABI definition for RISC-V 32-bit.

2018-11-29  Zong Li  <zong@andestech.com>

	* sysdeps/unix/sysv/linux/riscv/ldconfig.h (LD_SO_ABI): Support
	rv32.
---
 ChangeLog                                | 4 ++++
 sysdeps/unix/sysv/linux/riscv/ldconfig.h | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index 9854fb6df7..2a752ae444 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -14,6 +14,10 @@
 	* sysdeps/unix/sysv/linux/riscv/bits/timesize.h: Likewise.
 	* sysdeps/unix/sysv/linux/riscv/bits/typesizes.h: Likewise.
 
+2018-06-20  Zong Li  <zong@andestech.com>
+
+	* sysdeps/unix/sysv/linux/riscv/ldconfig.h (LD_SO_ABI): Support rv32.
+
 2019-06-20  Dmitry V. Levin  <ldv@altlinux.org>
 	    Florian Weimer  <fweimer@redhat.com>
 
diff --git a/sysdeps/unix/sysv/linux/riscv/ldconfig.h b/sysdeps/unix/sysv/linux/riscv/ldconfig.h
index 20fbd16c59..360f35fb28 100644
--- a/sysdeps/unix/sysv/linux/riscv/ldconfig.h
+++ b/sysdeps/unix/sysv/linux/riscv/ldconfig.h
@@ -24,7 +24,7 @@
 #if __riscv_xlen == 64
 # define LD_SO_ABI "riscv64-lp64"
 #else
-# error "rv32i-based targets are not supported"
+# define LD_SO_ABI "riscv32-ilp32"
 #endif
 
 #define SYSDEP_KNOWN_INTERPRETER_NAMES				\
-- 
2.22.0

[RFC v2 13/20] RISC-V: Add path of library directories for the 32-bit

[Alistair Francis]

From: Zong Li <zongbox@gmail.com>

For the recommand of 64 bit version, we add the libraries path of 32 bit
in this patch. This includes a fix to avoid an out of bound array check
when building with GCC 8.2.

2018-11-29  Zong Li  <zong@andestech.com>

	* sysdeps/unix/sysv/linux/riscv/dl-cache.h (add_system_dir): Add
	libraries path for rv32.

[ Changes by AF:
 - Fix bound array check when building with GCC 8.2
]
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
 ChangeLog                                |  3 +++
 sysdeps/unix/sysv/linux/riscv/dl-cache.h | 17 +++++++++++++++--
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 2a752ae444..73d07ab159 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -17,6 +17,9 @@
 2018-06-20  Zong Li  <zong@andestech.com>
 
 	* sysdeps/unix/sysv/linux/riscv/ldconfig.h (LD_SO_ABI): Support rv32.
+	* sysdeps/unix/sysv/linux/riscv/ldconfig.h (LD_SO_ABI): Support rv32.
+	* sysdeps/unix/sysv/linux/riscv/dl-cache.h (add_system_dir): Add
+	libraries path for rv32.
 
 2019-06-20  Dmitry V. Levin  <ldv@altlinux.org>
 	    Florian Weimer  <fweimer@redhat.com>
diff --git a/sysdeps/unix/sysv/linux/riscv/dl-cache.h b/sysdeps/unix/sysv/linux/riscv/dl-cache.h
index 2a15e28e3b..5943060536 100644
--- a/sysdeps/unix/sysv/linux/riscv/dl-cache.h
+++ b/sysdeps/unix/sysv/linux/riscv/dl-cache.h
@@ -34,6 +34,8 @@
    RISC-V, libraries can be found in paths ending in:
      - /lib64/lp64d
      - /lib64/lp64
+     - /lib32/ilp32d
+     - /lib32/ilp32
      - /lib (only ld.so)
    so this will add all of those paths.
 
@@ -49,9 +51,16 @@
   do							    		\
     {									\
       size_t len = strlen (dir);					\
-      char path[len + 9];						\
+      char path[len + 10];						\
       memcpy (path, dir, len + 1);					\
-      if (len >= 12 && ! memcmp(path + len - 12, "/lib64/lp64d", 12))	\
+      if (len >= 13 && ! memcmp(path + len - 13, "/lib32/ilp32d", 13))	\
+        {								\
+          len -= 9;							\
+	  path[len] = '\0';						\
+        }								\
+      if (len >= 12							\
+          && (! memcmp(path + len - 12, "/lib32/ilp32", 12)		\
+              || ! memcmp(path + len - 12, "/lib64/lp64d", 12)))	\
 	{								\
 	  len -= 8;							\
 	  path[len] = '\0';						\
@@ -64,6 +73,10 @@
       add_dir (path);							\
       if (len >= 4 && ! memcmp(path + len - 4, "/lib", 4))		\
 	{								\
+	  memcpy (path + len, "32/ilp32d", 10);				\
+	  add_dir (path);						\
+	  memcpy (path + len, "32/ilp32", 9);				\
+	  add_dir (path);						\
 	  memcpy (path + len, "64/lp64d", 9);				\
 	  add_dir (path);						\
 	  memcpy (path + len, "64/lp64", 8);				\
-- 
2.22.0

[RFC v2 14/20] RISC-V: The ABI implementation for the 32-bit

[Alistair Francis]

From: Zong Li <zongbox@gmail.com>

This patch adds the ABI implementation about 32 bit version. It contains
the Linux-specific and RISC-V architecture code, I've collected here.

2018-11-29  Zong Li  <zong@andestech.com>

	* sysdeps/riscv/bits/wordsize.h: Supprt rv32.
	* sysdeps/riscv/nptl/bits/pthreadtypes-arch.h: Likewise.
	* sysdeps/riscv/sfp-machine.h: Likewise.
	* sysdeps/riscv/sys/asm.h: Likewise.
	* sysdeps/unix/sysv/linux/riscv/rv32/jmp_buf-macros.h: New file.

[ Changes by AF:
 - Remove lock64.c
]
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
 ChangeLog                                     |  8 +++
 sysdeps/riscv/bits/wordsize.h                 |  4 +-
 sysdeps/riscv/nptl/bits/pthreadtypes-arch.h   | 25 ++++++++-
 sysdeps/riscv/sfp-machine.h                   | 27 +++++++++-
 sysdeps/riscv/sys/asm.h                       |  5 +-
 .../sysv/linux/riscv/rv32/jmp_buf-macros.h    | 53 +++++++++++++++++++
 6 files changed, 118 insertions(+), 4 deletions(-)
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/jmp_buf-macros.h

diff --git a/ChangeLog b/ChangeLog
index 73d07ab159..98bb7f600d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -20,6 +20,14 @@
 	* sysdeps/unix/sysv/linux/riscv/ldconfig.h (LD_SO_ABI): Support rv32.
 	* sysdeps/unix/sysv/linux/riscv/dl-cache.h (add_system_dir): Add
 	libraries path for rv32.
+	* sysdeps/unix/sysv/linux/riscv/ldconfig.h (LD_SO_ABI): Support rv32.
+	* sysdeps/unix/sysv/linux/riscv/dl-cache.h (add_system_dir): Add
+	libraries path for rv32.
+	* sysdeps/riscv/bits/wordsize.h: Supprt rv32.
+	* sysdeps/riscv/nptl/bits/pthreadtypes-arch.h: Likewise.
+	* sysdeps/riscv/sfp-machine.h: Likewise.
+	* sysdeps/riscv/sys/asm.h: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/rv32/jmp_buf-macros.h: New file.
 
 2019-06-20  Dmitry V. Levin  <ldv@altlinux.org>
 	    Florian Weimer  <fweimer@redhat.com>
diff --git a/sysdeps/riscv/bits/wordsize.h b/sysdeps/riscv/bits/wordsize.h
index 0b8cd8fefd..f10be0144c 100644
--- a/sysdeps/riscv/bits/wordsize.h
+++ b/sysdeps/riscv/bits/wordsize.h
@@ -25,5 +25,7 @@
 #if __riscv_xlen == 64
 # define __WORDSIZE_TIME64_COMPAT32 1
 #else
-# error "rv32i-based targets are not supported"
+# define __WORDSIZE_TIME64_COMPAT32 0
+# define __WORDSIZE32_SIZE_ULONG    0
+# define __WORDSIZE32_PTRDIFF_LONG  0
 #endif
diff --git a/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h b/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h
index e3fecc3208..4b08f7c692 100644
--- a/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h
+++ b/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h
@@ -32,7 +32,15 @@
 # define __SIZEOF_PTHREAD_BARRIER_T 		32
 # define __SIZEOF_PTHREAD_BARRIERATTR_T 	 4
 #else
-# error "rv32i-based systems are not supported"
+# define __SIZEOF_PTHREAD_ATTR_T 		32
+# define __SIZEOF_PTHREAD_MUTEX_T 		32
+# define __SIZEOF_PTHREAD_MUTEXATTR_T 		 4
+# define __SIZEOF_PTHREAD_COND_T 		48
+# define __SIZEOF_PTHREAD_CONDATTR_T 		 4
+# define __SIZEOF_PTHREAD_RWLOCK_T 		48
+# define __SIZEOF_PTHREAD_RWLOCKATTR_T 		 8
+# define __SIZEOF_PTHREAD_BARRIER_T 		20
+# define __SIZEOF_PTHREAD_BARRIERATTR_T 	 4
 #endif
 
 #define __PTHREAD_COMPAT_PADDING_MID
@@ -56,11 +64,26 @@ struct __pthread_rwlock_arch_t
   unsigned int __writers_futex;
   unsigned int __pad3;
   unsigned int __pad4;
+#if __riscv_xlen == 64
   int __cur_writer;
   int __shared;
   unsigned long int __pad1;
   unsigned long int __pad2;
   unsigned int __flags;
+#else
+# if __BYTE_ORDER == __BIG_ENDIAN
+  unsigned char __pad1;
+  unsigned char __pad2;
+  unsigned char __shared;
+  unsigned char __flags;
+# else
+  unsigned char __flags;
+  unsigned char __shared;
+  unsigned char __pad1;
+  unsigned char __pad2;
+# endif
+  int __cur_writer;
+#endif
 };
 
 #define __PTHREAD_RWLOCK_ELISION_EXTRA 		0
diff --git a/sysdeps/riscv/sfp-machine.h b/sysdeps/riscv/sfp-machine.h
index fa0b8fa41a..98e1f84370 100644
--- a/sysdeps/riscv/sfp-machine.h
+++ b/sysdeps/riscv/sfp-machine.h
@@ -22,7 +22,32 @@
 
 #if __riscv_xlen == 32
 
-# error "rv32i-based targets are not supported"
+# define _FP_W_TYPE_SIZE		32
+# define _FP_W_TYPE		unsigned long
+# define _FP_WS_TYPE		signed long
+# define _FP_I_TYPE		long
+
+# define _FP_MUL_MEAT_S(R, X, Y)				\
+  _FP_MUL_MEAT_1_wide (_FP_WFRACBITS_S, R, X, Y, umul_ppmm)
+# define _FP_MUL_MEAT_D(R, X, Y)				\
+  _FP_MUL_MEAT_2_wide (_FP_WFRACBITS_D, R, X, Y, umul_ppmm)
+# define _FP_MUL_MEAT_Q(R, X, Y)				\
+  _FP_MUL_MEAT_4_wide (_FP_WFRACBITS_Q, R, X, Y, umul_ppmm)
+
+# define _FP_MUL_MEAT_DW_S(R, X, Y)					\
+  _FP_MUL_MEAT_DW_1_wide (_FP_WFRACBITS_S, R, X, Y, umul_ppmm)
+# define _FP_MUL_MEAT_DW_D(R, X, Y)					\
+  _FP_MUL_MEAT_DW_2_wide (_FP_WFRACBITS_D, R, X, Y, umul_ppmm)
+# define _FP_MUL_MEAT_DW_Q(R, X, Y)					\
+  _FP_MUL_MEAT_DW_4_wide (_FP_WFRACBITS_Q, R, X, Y, umul_ppmm)
+
+# define _FP_DIV_MEAT_S(R, X, Y)	_FP_DIV_MEAT_1_udiv_norm (S, R, X, Y)
+# define _FP_DIV_MEAT_D(R, X, Y)	_FP_DIV_MEAT_2_udiv (D, R, X, Y)
+# define _FP_DIV_MEAT_Q(R, X, Y)	_FP_DIV_MEAT_4_udiv (Q, R, X, Y)
+
+# define _FP_NANFRAC_S		_FP_QNANBIT_S
+# define _FP_NANFRAC_D		_FP_QNANBIT_D, 0
+# define _FP_NANFRAC_Q		_FP_QNANBIT_Q, 0, 0, 0
 
 #else
 
diff --git a/sysdeps/riscv/sys/asm.h b/sysdeps/riscv/sys/asm.h
index b8f90a44ce..7ea34afd6d 100644
--- a/sysdeps/riscv/sys/asm.h
+++ b/sysdeps/riscv/sys/asm.h
@@ -26,7 +26,10 @@
 # define REG_S sd
 # define REG_L ld
 #elif __riscv_xlen == 32
-# error "rv32i-based targets are not supported"
+# define PTRLOG 2
+# define SZREG	4
+# define REG_S sw
+# define REG_L lw
 #else
 # error __riscv_xlen must equal 32 or 64
 #endif
diff --git a/sysdeps/unix/sysv/linux/riscv/rv32/jmp_buf-macros.h b/sysdeps/unix/sysv/linux/riscv/rv32/jmp_buf-macros.h
new file mode 100644
index 0000000000..e0042b9f01
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/rv32/jmp_buf-macros.h
@@ -0,0 +1,53 @@
+/* jump buffer constants for RISC-V
+   Copyright (C) 2017-2018 Free Software Foundation, Inc.
+
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library.  If not, see
+   <http://www.gnu.org/licenses/>.  */
+
+/* Produced by this program:
+
+   #include <stdio.h>
+   #include <unistd.h>
+   #include <setjmp.h>
+   #include <stddef.h>
+
+   int main (int argc, char **argv)
+   {
+       printf ("#define JMP_BUF_SIZE %d\n", sizeof (jmp_buf));
+       printf ("#define JMP_BUF_ALIGN %d\n", __alignof__ (jmp_buf));
+       printf ("#define SIGJMP_BUF_SIZE %d\n", sizeof (sigjmp_buf));
+       printf ("#define SIGJMP_BUF_ALIGN %d\n", __alignof__ (sigjmp_buf));
+       printf ("#define MASK_WAS_SAVED_OFFSET %d\n", offsetof (struct __jmp_buf_tag, __mask_was_saved));
+       printf ("#define SAVED_MASK_OFFSET %d\n", offsetof (struct __jmp_buf_tag, __saved_mask));
+   } */
+
+#if defined __riscv_float_abi_soft
+# define JMP_BUF_SIZE 188
+# define JMP_BUF_ALIGN 4
+# define SIGJMP_BUF_SIZE 188
+# define SIGJMP_BUF_ALIGN 4
+# define MASK_WAS_SAVED_OFFSET 56
+# define SAVED_MASK_OFFSET 60
+#elif defined __riscv_float_abi_double
+# define JMP_BUF_SIZE 288
+# define JMP_BUF_ALIGN 8
+# define SIGJMP_BUF_SIZE 288
+# define SIGJMP_BUF_ALIGN 8
+# define MASK_WAS_SAVED_OFFSET 152
+# define SAVED_MASK_OFFSET 156
+#else
+# error "Unknown RISC-V floating-point ABI"
+#endif
-- 
2.22.0

[RFC v2 15/20] RISC-V: Hard float support for the 32 bit

[Alistair Francis]

From: Zong Li <zongbox@gmail.com>

This patch contains hardware floating-point support for the RV32IF and
RV32IFD

2018-11-29  Zong Li  <zong@andestech.com>

	* sysdeps/riscv/rv32/rvd/s_lrint.c: New file.
	* sysdeps/riscv/rv32/rvd/s_lround.c: Likewise.
	* sysdeps/riscv/rv32/rvf/s_lrintf.c: Likewise.
	* sysdeps/riscv/rv32/rvf/s_lroundf.c: Likewise.
---
 ChangeLog                          |  4 ++++
 sysdeps/riscv/rv32/rvd/s_lrint.c   | 31 ++++++++++++++++++++++++++++++
 sysdeps/riscv/rv32/rvd/s_lround.c  | 31 ++++++++++++++++++++++++++++++
 sysdeps/riscv/rv32/rvf/s_lrintf.c  | 31 ++++++++++++++++++++++++++++++
 sysdeps/riscv/rv32/rvf/s_lroundf.c | 31 ++++++++++++++++++++++++++++++
 5 files changed, 128 insertions(+)
 create mode 100644 sysdeps/riscv/rv32/rvd/s_lrint.c
 create mode 100644 sysdeps/riscv/rv32/rvd/s_lround.c
 create mode 100644 sysdeps/riscv/rv32/rvf/s_lrintf.c
 create mode 100644 sysdeps/riscv/rv32/rvf/s_lroundf.c

diff --git a/ChangeLog b/ChangeLog
index 98bb7f600d..b25e734556 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -28,6 +28,10 @@
 	* sysdeps/riscv/sfp-machine.h: Likewise.
 	* sysdeps/riscv/sys/asm.h: Likewise.
 	* sysdeps/unix/sysv/linux/riscv/rv32/jmp_buf-macros.h: New file.
+	* sysdeps/riscv/rv32/rvd/s_lrint.c: New file.
+	* sysdeps/riscv/rv32/rvd/s_lround.c: Likewise.
+	* sysdeps/riscv/rv32/rvf/s_lrintf.c: Likewise.
+	* sysdeps/riscv/rv32/rvf/s_lroundf.c: Likewise.
 
 2019-06-20  Dmitry V. Levin  <ldv@altlinux.org>
 	    Florian Weimer  <fweimer@redhat.com>
diff --git a/sysdeps/riscv/rv32/rvd/s_lrint.c b/sysdeps/riscv/rv32/rvd/s_lrint.c
new file mode 100644
index 0000000000..4d5bdbc200
--- /dev/null
+++ b/sysdeps/riscv/rv32/rvd/s_lrint.c
@@ -0,0 +1,31 @@
+/* lrint().  RISC-V version.
+   Copyright (C) 2017-2018 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library.  If not, see
+   <http://www.gnu.org/licenses/>.  */
+
+#include <math.h>
+#include <libm-alias-double.h>
+#include <stdint.h>
+
+long int
+__lrint (double x)
+{
+  int32_t res;
+  asm ("fcvt.w.d %0, %1" : "=r" (res) : "f" (x));
+  return res;
+}
+
+libm_alias_double (__lrint, lrint)
diff --git a/sysdeps/riscv/rv32/rvd/s_lround.c b/sysdeps/riscv/rv32/rvd/s_lround.c
new file mode 100644
index 0000000000..f5d9cf2e07
--- /dev/null
+++ b/sysdeps/riscv/rv32/rvd/s_lround.c
@@ -0,0 +1,31 @@
+/* lround().  RISC-V version.
+   Copyright (C) 2017-2018 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library.  If not, see
+   <http://www.gnu.org/licenses/>.  */
+
+#include <math.h>
+#include <libm-alias-double.h>
+#include <stdint.h>
+
+long int
+__lround (double x)
+{
+  int32_t res;
+  asm ("fcvt.w.d %0, %1, rmm" : "=r" (res) : "f" (x));
+  return res;
+}
+
+libm_alias_double (__lround, lround)
diff --git a/sysdeps/riscv/rv32/rvf/s_lrintf.c b/sysdeps/riscv/rv32/rvf/s_lrintf.c
new file mode 100644
index 0000000000..08d44fa738
--- /dev/null
+++ b/sysdeps/riscv/rv32/rvf/s_lrintf.c
@@ -0,0 +1,31 @@
+/* lrintf().  RISC-V version.
+   Copyright (C) 2017-2018 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library.  If not, see
+   <http://www.gnu.org/licenses/>.  */
+
+#include <math.h>
+#include <libm-alias-float.h>
+#include <stdint.h>
+
+long int
+__lrintf (float x)
+{
+  int32_t res;
+  asm ("fcvt.w.s %0, %1" : "=r" (res) : "f" (x));
+  return res;
+}
+
+libm_alias_float (__lrint, lrint)
diff --git a/sysdeps/riscv/rv32/rvf/s_lroundf.c b/sysdeps/riscv/rv32/rvf/s_lroundf.c
new file mode 100644
index 0000000000..f31b432936
--- /dev/null
+++ b/sysdeps/riscv/rv32/rvf/s_lroundf.c
@@ -0,0 +1,31 @@
+/* lroundf().  RISC-V version.
+   Copyright (C) 2017-2018 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library.  If not, see
+   <http://www.gnu.org/licenses/>.  */
+
+#include <math.h>
+#include <libm-alias-float.h>
+#include <stdint.h>
+
+long int
+__lroundf (float x)
+{
+  int32_t res;
+  asm ("fcvt.w.s %0, %1, rmm" : "=r" (res) : "f" (x));
+  return res;
+}
+
+libm_alias_float (__lround, lround)
-- 
2.22.0

[RFC v2 16/20] RISC-V: Regenerate ULPs of RISC-V

[Alistair Francis]

From: Zong Li <zongbox@gmail.com>

Use the regen-ulp to generate the ulp files of rvd and nofpu. The RV32
and RV64 use the same ulps.

2018-11-29  Zong Li  <zong@andestech.com>

	* sysdeps/riscv/nofpu/libm-test-ulps: Regenerate.
	* sysdeps/riscv/rvd/libm-test-ulps: New file.
	* sysdeps/riscv/rvd/libm-test-ulps-name: New file.
	* sysdeps/riscv/rv64/rvd/libm-test-ulps: Remove file.
	* sysdeps/riscv/rv64/rvd/libm-test-ulps-name: Remove file.
---
 ChangeLog                                     | 18 ++++++
 sysdeps/riscv/nofpu/libm-test-ulps            | 16 +++---
 sysdeps/riscv/{rv64 => }/rvd/libm-test-ulps   | 56 +++++++++----------
 .../riscv/{rv64 => }/rvd/libm-test-ulps-name  |  0
 4 files changed, 54 insertions(+), 36 deletions(-)
 rename sysdeps/riscv/{rv64 => }/rvd/libm-test-ulps (98%)
 rename sysdeps/riscv/{rv64 => }/rvd/libm-test-ulps-name (100%)

diff --git a/ChangeLog b/ChangeLog
index b25e734556..d53aac60c6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -32,6 +32,24 @@
 	* sysdeps/riscv/rv32/rvd/s_lround.c: Likewise.
 	* sysdeps/riscv/rv32/rvf/s_lrintf.c: Likewise.
 	* sysdeps/riscv/rv32/rvf/s_lroundf.c: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/ldconfig.h (LD_SO_ABI): Support rv32.
+	* sysdeps/unix/sysv/linux/riscv/dl-cache.h (add_system_dir): Add
+	libraries path for rv32.
+	* sysdeps/riscv/bits/wordsize.h: Supprt rv32.
+	* sysdeps/riscv/nptl/bits/pthreadtypes-arch.h: Likewise.
+	* sysdeps/riscv/sfp-machine.h: Likewise.
+	* sysdeps/riscv/sys/asm.h: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/rv32/jmp_buf-macros.h: New file.
+	* sysdeps/unix/sysv/linux/riscv/rv32/lockf64.c: Likewise.
+	* sysdeps/riscv/rv32/rvd/s_lrint.c: New file.
+	* sysdeps/riscv/rv32/rvd/s_lround.c: Likewise.
+	* sysdeps/riscv/rv32/rvf/s_lrintf.c: Likewise.
+	* sysdeps/riscv/rv32/rvf/s_lroundf.c: Likewise.
+	* sysdeps/riscv/nofpu/libm-test-ulps: Regenerate.
+	* sysdeps/riscv/rvd/libm-test-ulps: New file.
+	* sysdeps/riscv/rvd/libm-test-ulps-name: New file.
+	* sysdeps/riscv/rv64/rvd/libm-test-ulps: Remove file.
+	* sysdeps/riscv/rv64/rvd/libm-test-ulps-name: Remove file.
 
 2019-06-20  Dmitry V. Levin  <ldv@altlinux.org>
 	    Florian Weimer  <fweimer@redhat.com>
diff --git a/sysdeps/riscv/nofpu/libm-test-ulps b/sysdeps/riscv/nofpu/libm-test-ulps
index 700772a5bf..102144a428 100644
--- a/sysdeps/riscv/nofpu/libm-test-ulps
+++ b/sysdeps/riscv/nofpu/libm-test-ulps
@@ -532,16 +532,16 @@ double: 1
 float: 1
 idouble: 1
 ifloat: 1
-ildouble: 1
-ldouble: 1
+ildouble: 8
+ldouble: 8
 
 Function: Imaginary part of "catan":
 double: 1
 float: 1
 idouble: 1
 ifloat: 1
-ildouble: 1
-ldouble: 1
+ildouble: 4
+ldouble: 4
 
 Function: Real part of "catan_downward":
 double: 1
@@ -596,16 +596,16 @@ double: 1
 float: 1
 idouble: 1
 ifloat: 1
-ildouble: 1
-ldouble: 1
+ildouble: 4
+ldouble: 4
 
 Function: Imaginary part of "catanh":
 double: 1
 float: 1
 idouble: 1
 ifloat: 1
-ildouble: 1
-ldouble: 1
+ildouble: 8
+ldouble: 8
 
 Function: Real part of "catanh_downward":
 double: 2
diff --git a/sysdeps/riscv/rv64/rvd/libm-test-ulps b/sysdeps/riscv/rvd/libm-test-ulps
similarity index 98%
rename from sysdeps/riscv/rv64/rvd/libm-test-ulps
rename to sysdeps/riscv/rvd/libm-test-ulps
index 971373d87d..aff168f7bd 100644
--- a/sysdeps/riscv/rv64/rvd/libm-test-ulps
+++ b/sysdeps/riscv/rvd/libm-test-ulps
@@ -532,56 +532,56 @@ double: 1
 float: 1
 idouble: 1
 ifloat: 1
-ildouble: 1
-ldouble: 1
+ildouble: 8
+ldouble: 8
 
 Function: Imaginary part of "catan":
 double: 1
 float: 1
 idouble: 1
 ifloat: 1
-ildouble: 1
-ldouble: 1
+ildouble: 4
+ldouble: 4
 
 Function: Real part of "catan_downward":
 double: 1
 float: 2
 idouble: 1
 ifloat: 2
-ildouble: 2
-ldouble: 2
+ildouble: 9
+ldouble: 9
 
 Function: Imaginary part of "catan_downward":
 double: 2
 float: 2
 idouble: 2
 ifloat: 2
-ildouble: 2
-ldouble: 2
+ildouble: 3
+ldouble: 3
 
 Function: Real part of "catan_towardzero":
 double: 1
 float: 2
 idouble: 1
 ifloat: 2
-ildouble: 2
-ldouble: 2
+ildouble: 9
+ldouble: 9
 
 Function: Imaginary part of "catan_towardzero":
 double: 2
 float: 2
 idouble: 2
 ifloat: 2
-ildouble: 2
-ldouble: 2
+ildouble: 3
+ldouble: 3
 
 Function: Real part of "catan_upward":
 double: 1
 float: 1
 idouble: 1
 ifloat: 1
-ildouble: 2
-ldouble: 2
+ildouble: 8
+ldouble: 8
 
 Function: Imaginary part of "catan_upward":
 double: 2
@@ -596,48 +596,48 @@ double: 1
 float: 1
 idouble: 1
 ifloat: 1
-ildouble: 1
-ldouble: 1
+ildouble: 4
+ldouble: 4
 
 Function: Imaginary part of "catanh":
 double: 1
 float: 1
 idouble: 1
 ifloat: 1
-ildouble: 1
-ldouble: 1
+ildouble: 8
+ldouble: 8
 
 Function: Real part of "catanh_downward":
 double: 2
 float: 2
 idouble: 2
 ifloat: 2
-ildouble: 2
-ldouble: 2
+ildouble: 3
+ldouble: 3
 
 Function: Imaginary part of "catanh_downward":
 double: 1
 float: 2
 idouble: 1
 ifloat: 2
-ildouble: 2
-ldouble: 2
+ildouble: 9
+ldouble: 9
 
 Function: Real part of "catanh_towardzero":
 double: 2
 float: 2
 idouble: 2
 ifloat: 2
-ildouble: 2
-ldouble: 2
+ildouble: 3
+ldouble: 3
 
 Function: Imaginary part of "catanh_towardzero":
 double: 1
 float: 2
 idouble: 1
 ifloat: 2
-ildouble: 2
-ldouble: 2
+ildouble: 9
+ldouble: 9
 
 Function: Real part of "catanh_upward":
 double: 4
@@ -652,8 +652,8 @@ double: 1
 float: 1
 idouble: 1
 ifloat: 1
-ildouble: 2
-ldouble: 2
+ildouble: 8
+ldouble: 8
 
 Function: "cbrt":
 double: 3
diff --git a/sysdeps/riscv/rv64/rvd/libm-test-ulps-name b/sysdeps/riscv/rvd/libm-test-ulps-name
similarity index 100%
rename from sysdeps/riscv/rv64/rvd/libm-test-ulps-name
rename to sysdeps/riscv/rvd/libm-test-ulps-name
-- 
2.22.0

[RFC v2 17/20] RISC-V: Add ABI lists

[Alistair Francis]

From: Zong Li <zongbox@gmail.com>

Use the check-api and update-abi to generate the abilist for rv32.

2018-11-29  Zong Li  <zong@andestech.com>

	* sysdeps/unix/sysv/linux/riscv/rv32/c++-types.data: New file.
	* sysdeps/unix/sysv/linux/riscv/rv32/ld.abilist: Likewise.
	* sysdeps/unix/sysv/linux/riscv/rv32/libanl.abilist: Likewise.
	* sysdeps/unix/sysv/linux/riscv/rv32/libc.abilist: Likewise.
	* sysdeps/unix/sysv/linux/riscv/rv32/libcrypt.abilist: Likewise.
	* sysdeps/unix/sysv/linux/riscv/rv32/libdl.abilist: Likewise.
	* sysdeps/unix/sysv/linux/riscv/rv32/libm.abilist: Likewise.
	* sysdeps/unix/sysv/linux/riscv/rv32/libpthread.abilist: Likewise.
	* sysdeps/unix/sysv/linux/riscv/rv32/libresolv.abilist: Likewise.
	* sysdeps/unix/sysv/linux/riscv/rv32/librt.abilist: Likewise.
	* sysdeps/unix/sysv/linux/riscv/rv32/libthread_db.abilist: Likewise.
	* sysdeps/unix/sysv/linux/riscv/rv32/libutil.abilist: Likewise.
	* sysdeps/unix/sysv/linux/riscv/rv32/libBrokenLocale.abilist:
	Likewise.
---
 ChangeLog                                     |   32 +
 .../unix/sysv/linux/riscv/rv32/c++-types.data |   67 +
 sysdeps/unix/sysv/linux/riscv/rv32/ld.abilist |    9 +
 .../linux/riscv/rv32/libBrokenLocale.abilist  |    1 +
 .../unix/sysv/linux/riscv/rv32/libanl.abilist |    4 +
 .../unix/sysv/linux/riscv/rv32/libc.abilist   | 2101 +++++++++++++++++
 .../sysv/linux/riscv/rv32/libcrypt.abilist    |    2 +
 .../unix/sysv/linux/riscv/rv32/libdl.abilist  |    9 +
 .../unix/sysv/linux/riscv/rv32/libm.abilist   | 1021 ++++++++
 .../sysv/linux/riscv/rv32/libpthread.abilist  |  235 ++
 .../sysv/linux/riscv/rv32/libresolv.abilist   |   79 +
 .../unix/sysv/linux/riscv/rv32/librt.abilist  |   35 +
 .../linux/riscv/rv32/libthread_db.abilist     |   40 +
 .../sysv/linux/riscv/rv32/libutil.abilist     |    6 +
 14 files changed, 3641 insertions(+)
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/c++-types.data
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/ld.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libBrokenLocale.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libanl.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libc.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libcrypt.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libdl.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libm.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libpthread.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libresolv.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/librt.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libthread_db.abilist
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libutil.abilist

diff --git a/ChangeLog b/ChangeLog
index d53aac60c6..704d425a95 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -50,6 +50,38 @@
 	* sysdeps/riscv/rvd/libm-test-ulps-name: New file.
 	* sysdeps/riscv/rv64/rvd/libm-test-ulps: Remove file.
 	* sysdeps/riscv/rv64/rvd/libm-test-ulps-name: Remove file.
+	* sysdeps/unix/sysv/linux/riscv/ldconfig.h (LD_SO_ABI): Support rv32.
+	* sysdeps/unix/sysv/linux/riscv/dl-cache.h (add_system_dir): Add
+	libraries path for rv32.
+	* sysdeps/riscv/bits/wordsize.h: Supprt rv32.
+	* sysdeps/riscv/nptl/bits/pthreadtypes-arch.h: Likewise.
+	* sysdeps/riscv/sfp-machine.h: Likewise.
+	* sysdeps/riscv/sys/asm.h: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/rv32/jmp_buf-macros.h: New file.
+	* sysdeps/unix/sysv/linux/riscv/rv32/lockf64.c: Likewise.
+	* sysdeps/riscv/rv32/rvd/s_lrint.c: New file.
+	* sysdeps/riscv/rv32/rvd/s_lround.c: Likewise.
+	* sysdeps/riscv/rv32/rvf/s_lrintf.c: Likewise.
+	* sysdeps/riscv/rv32/rvf/s_lroundf.c: Likewise.
+	* sysdeps/riscv/nofpu/libm-test-ulps: Regenerate.
+	* sysdeps/riscv/rvd/libm-test-ulps: New file.
+	* sysdeps/riscv/rvd/libm-test-ulps-name: New file.
+	* sysdeps/riscv/rv64/rvd/libm-test-ulps: Remove file.
+	* sysdeps/riscv/rv64/rvd/libm-test-ulps-name: Remove file.
+	* sysdeps/unix/sysv/linux/riscv/rv32/c++-types.data: New file.
+	* sysdeps/unix/sysv/linux/riscv/rv32/ld.abilist: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/rv32/libanl.abilist: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/rv32/libc.abilist: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/rv32/libcrypt.abilist: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/rv32/libdl.abilist: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/rv32/libm.abilist: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/rv32/libpthread.abilist: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/rv32/libresolv.abilist: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/rv32/librt.abilist: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/rv32/libthread_db.abilist: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/rv32/libutil.abilist: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/rv32/libBrokenLocale.abilist:
+	Likewise.
 
 2019-06-20  Dmitry V. Levin  <ldv@altlinux.org>
 	    Florian Weimer  <fweimer@redhat.com>
diff --git a/sysdeps/unix/sysv/linux/riscv/rv32/c++-types.data b/sysdeps/unix/sysv/linux/riscv/rv32/c++-types.data
new file mode 100644
index 0000000000..303f4570c8
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/rv32/c++-types.data
@@ -0,0 +1,67 @@
+blkcnt64_t:x
+blkcnt_t:l
+blksize_t:i
+caddr_t:Pc
+clockid_t:i
+clock_t:l
+daddr_t:i
+dev_t:y
+fd_mask:l
+fsblkcnt64_t:y
+fsblkcnt_t:m
+fsfilcnt64_t:y
+fsfilcnt_t:m
+fsid_t:8__fsid_t
+gid_t:j
+id_t:j
+ino64_t:y
+ino_t:m
+int16_t:s
+int32_t:i
+int64_t:x
+int8_t:a
+intptr_t:i
+key_t:i
+loff_t:x
+mode_t:j
+nlink_t:j
+off64_t:x
+off_t:l
+pid_t:i
+pthread_attr_t:14pthread_attr_t
+pthread_barrier_t:17pthread_barrier_t
+pthread_barrierattr_t:21pthread_barrierattr_t
+pthread_cond_t:14pthread_cond_t
+pthread_condattr_t:18pthread_condattr_t
+pthread_key_t:j
+pthread_mutex_t:15pthread_mutex_t
+pthread_mutexattr_t:19pthread_mutexattr_t
+pthread_once_t:i
+pthread_rwlock_t:16pthread_rwlock_t
+pthread_rwlockattr_t:20pthread_rwlockattr_t
+pthread_spinlock_t:i
+pthread_t:m
+quad_t:x
+register_t:i
+rlim64_t:y
+rlim_t:m
+sigset_t:10__sigset_t
+size_t:j
+socklen_t:j
+ssize_t:i
+suseconds_t:l
+time_t:l
+u_char:h
+uid_t:j
+uint:j
+u_int:j
+u_int16_t:t
+u_int32_t:j
+u_int64_t:y
+u_int8_t:h
+ulong:m
+u_long:m
+u_quad_t:y
+useconds_t:j
+ushort:t
+u_short:t
diff --git a/sysdeps/unix/sysv/linux/riscv/rv32/ld.abilist b/sysdeps/unix/sysv/linux/riscv/rv32/ld.abilist
new file mode 100644
index 0000000000..71576160ed
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/rv32/ld.abilist
@@ -0,0 +1,9 @@
+GLIBC_2.29 __libc_stack_end D 0x4
+GLIBC_2.29 __stack_chk_guard D 0x4
+GLIBC_2.29 __tls_get_addr F
+GLIBC_2.29 _dl_mcount F
+GLIBC_2.29 _r_debug D 0x14
+GLIBC_2.29 calloc F
+GLIBC_2.29 free F
+GLIBC_2.29 malloc F
+GLIBC_2.29 realloc F
diff --git a/sysdeps/unix/sysv/linux/riscv/rv32/libBrokenLocale.abilist b/sysdeps/unix/sysv/linux/riscv/rv32/libBrokenLocale.abilist
new file mode 100644
index 0000000000..96b4163a25
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/rv32/libBrokenLocale.abilist
@@ -0,0 +1 @@
+GLIBC_2.29 __ctype_get_mb_cur_max F
diff --git a/sysdeps/unix/sysv/linux/riscv/rv32/libanl.abilist b/sysdeps/unix/sysv/linux/riscv/rv32/libanl.abilist
new file mode 100644
index 0000000000..416a6f8ddb
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/rv32/libanl.abilist
@@ -0,0 +1,4 @@
+GLIBC_2.29 gai_cancel F
+GLIBC_2.29 gai_error F
+GLIBC_2.29 gai_suspend F
+GLIBC_2.29 getaddrinfo_a F
diff --git a/sysdeps/unix/sysv/linux/riscv/rv32/libc.abilist b/sysdeps/unix/sysv/linux/riscv/rv32/libc.abilist
new file mode 100644
index 0000000000..d8035d72b2
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/rv32/libc.abilist
@@ -0,0 +1,2101 @@
+GLIBC_2.29 _Exit F
+GLIBC_2.29 _IO_2_1_stderr_ D 0xa0
+GLIBC_2.29 _IO_2_1_stdin_ D 0xa0
+GLIBC_2.29 _IO_2_1_stdout_ D 0xa0
+GLIBC_2.29 _IO_adjust_column F
+GLIBC_2.29 _IO_adjust_wcolumn F
+GLIBC_2.29 _IO_default_doallocate F
+GLIBC_2.29 _IO_default_finish F
+GLIBC_2.29 _IO_default_pbackfail F
+GLIBC_2.29 _IO_default_uflow F
+GLIBC_2.29 _IO_default_xsgetn F
+GLIBC_2.29 _IO_default_xsputn F
+GLIBC_2.29 _IO_do_write F
+GLIBC_2.29 _IO_doallocbuf F
+GLIBC_2.29 _IO_fclose F
+GLIBC_2.29 _IO_fdopen F
+GLIBC_2.29 _IO_feof F
+GLIBC_2.29 _IO_ferror F
+GLIBC_2.29 _IO_fflush F
+GLIBC_2.29 _IO_fgetpos F
+GLIBC_2.29 _IO_fgetpos64 F
+GLIBC_2.29 _IO_fgets F
+GLIBC_2.29 _IO_file_attach F
+GLIBC_2.29 _IO_file_close F
+GLIBC_2.29 _IO_file_close_it F
+GLIBC_2.29 _IO_file_doallocate F
+GLIBC_2.29 _IO_file_finish F
+GLIBC_2.29 _IO_file_fopen F
+GLIBC_2.29 _IO_file_init F
+GLIBC_2.29 _IO_file_jumps D 0x54
+GLIBC_2.29 _IO_file_open F
+GLIBC_2.29 _IO_file_overflow F
+GLIBC_2.29 _IO_file_read F
+GLIBC_2.29 _IO_file_seek F
+GLIBC_2.29 _IO_file_seekoff F
+GLIBC_2.29 _IO_file_setbuf F
+GLIBC_2.29 _IO_file_stat F
+GLIBC_2.29 _IO_file_sync F
+GLIBC_2.29 _IO_file_underflow F
+GLIBC_2.29 _IO_file_write F
+GLIBC_2.29 _IO_file_xsputn F
+GLIBC_2.29 _IO_flockfile F
+GLIBC_2.29 _IO_flush_all F
+GLIBC_2.29 _IO_flush_all_linebuffered F
+GLIBC_2.29 _IO_fopen F
+GLIBC_2.29 _IO_fprintf F
+GLIBC_2.29 _IO_fputs F
+GLIBC_2.29 _IO_fread F
+GLIBC_2.29 _IO_free_backup_area F
+GLIBC_2.29 _IO_free_wbackup_area F
+GLIBC_2.29 _IO_fsetpos F
+GLIBC_2.29 _IO_fsetpos64 F
+GLIBC_2.29 _IO_ftell F
+GLIBC_2.29 _IO_ftrylockfile F
+GLIBC_2.29 _IO_funlockfile F
+GLIBC_2.29 _IO_fwrite F
+GLIBC_2.29 _IO_getc F
+GLIBC_2.29 _IO_getline F
+GLIBC_2.29 _IO_getline_info F
+GLIBC_2.29 _IO_gets F
+GLIBC_2.29 _IO_init F
+GLIBC_2.29 _IO_init_marker F
+GLIBC_2.29 _IO_init_wmarker F
+GLIBC_2.29 _IO_iter_begin F
+GLIBC_2.29 _IO_iter_end F
+GLIBC_2.29 _IO_iter_file F
+GLIBC_2.29 _IO_iter_next F
+GLIBC_2.29 _IO_least_wmarker F
+GLIBC_2.29 _IO_link_in F
+GLIBC_2.29 _IO_list_all D 0x4
+GLIBC_2.29 _IO_list_lock F
+GLIBC_2.29 _IO_list_resetlock F
+GLIBC_2.29 _IO_list_unlock F
+GLIBC_2.29 _IO_marker_delta F
+GLIBC_2.29 _IO_marker_difference F
+GLIBC_2.29 _IO_padn F
+GLIBC_2.29 _IO_peekc_locked F
+GLIBC_2.29 _IO_popen F
+GLIBC_2.29 _IO_printf F
+GLIBC_2.29 _IO_proc_close F
+GLIBC_2.29 _IO_proc_open F
+GLIBC_2.29 _IO_putc F
+GLIBC_2.29 _IO_puts F
+GLIBC_2.29 _IO_remove_marker F
+GLIBC_2.29 _IO_seekmark F
+GLIBC_2.29 _IO_seekoff F
+GLIBC_2.29 _IO_seekpos F
+GLIBC_2.29 _IO_seekwmark F
+GLIBC_2.29 _IO_setb F
+GLIBC_2.29 _IO_setbuffer F
+GLIBC_2.29 _IO_setvbuf F
+GLIBC_2.29 _IO_sgetn F
+GLIBC_2.29 _IO_sprintf F
+GLIBC_2.29 _IO_sputbackc F
+GLIBC_2.29 _IO_sputbackwc F
+GLIBC_2.29 _IO_sscanf F
+GLIBC_2.29 _IO_str_init_readonly F
+GLIBC_2.29 _IO_str_init_static F
+GLIBC_2.29 _IO_str_overflow F
+GLIBC_2.29 _IO_str_pbackfail F
+GLIBC_2.29 _IO_str_seekoff F
+GLIBC_2.29 _IO_str_underflow F
+GLIBC_2.29 _IO_sungetc F
+GLIBC_2.29 _IO_sungetwc F
+GLIBC_2.29 _IO_switch_to_get_mode F
+GLIBC_2.29 _IO_switch_to_main_wget_area F
+GLIBC_2.29 _IO_switch_to_wbackup_area F
+GLIBC_2.29 _IO_switch_to_wget_mode F
+GLIBC_2.29 _IO_un_link F
+GLIBC_2.29 _IO_ungetc F
+GLIBC_2.29 _IO_unsave_markers F
+GLIBC_2.29 _IO_unsave_wmarkers F
+GLIBC_2.29 _IO_vfprintf F
+GLIBC_2.29 _IO_vsprintf F
+GLIBC_2.29 _IO_wdefault_doallocate F
+GLIBC_2.29 _IO_wdefault_finish F
+GLIBC_2.29 _IO_wdefault_pbackfail F
+GLIBC_2.29 _IO_wdefault_uflow F
+GLIBC_2.29 _IO_wdefault_xsgetn F
+GLIBC_2.29 _IO_wdefault_xsputn F
+GLIBC_2.29 _IO_wdo_write F
+GLIBC_2.29 _IO_wdoallocbuf F
+GLIBC_2.29 _IO_wfile_jumps D 0x54
+GLIBC_2.29 _IO_wfile_overflow F
+GLIBC_2.29 _IO_wfile_seekoff F
+GLIBC_2.29 _IO_wfile_sync F
+GLIBC_2.29 _IO_wfile_underflow F
+GLIBC_2.29 _IO_wfile_xsputn F
+GLIBC_2.29 _IO_wmarker_delta F
+GLIBC_2.29 _IO_wsetb F
+GLIBC_2.29 ___brk_addr D 0x4
+GLIBC_2.29 __adjtimex F
+GLIBC_2.29 __after_morecore_hook D 0x4
+GLIBC_2.29 __argz_count F
+GLIBC_2.29 __argz_next F
+GLIBC_2.29 __argz_stringify F
+GLIBC_2.29 __asprintf F
+GLIBC_2.29 __asprintf_chk F
+GLIBC_2.29 __assert F
+GLIBC_2.29 __assert_fail F
+GLIBC_2.29 __assert_perror_fail F
+GLIBC_2.29 __backtrace F
+GLIBC_2.29 __backtrace_symbols F
+GLIBC_2.29 __backtrace_symbols_fd F
+GLIBC_2.29 __bsd_getpgrp F
+GLIBC_2.29 __bzero F
+GLIBC_2.29 __check_rhosts_file D 0x4
+GLIBC_2.29 __chk_fail F
+GLIBC_2.29 __clone F
+GLIBC_2.29 __close F
+GLIBC_2.29 __cmsg_nxthdr F
+GLIBC_2.29 __confstr_chk F
+GLIBC_2.29 __connect F
+GLIBC_2.29 __ctype_b_loc F
+GLIBC_2.29 __ctype_get_mb_cur_max F
+GLIBC_2.29 __ctype_tolower_loc F
+GLIBC_2.29 __ctype_toupper_loc F
+GLIBC_2.29 __curbrk D 0x4
+GLIBC_2.29 __cxa_at_quick_exit F
+GLIBC_2.29 __cxa_atexit F
+GLIBC_2.29 __cxa_finalize F
+GLIBC_2.29 __cxa_thread_atexit_impl F
+GLIBC_2.29 __cyg_profile_func_enter F
+GLIBC_2.29 __cyg_profile_func_exit F
+GLIBC_2.29 __daylight D 0x4
+GLIBC_2.29 __dcgettext F
+GLIBC_2.29 __default_morecore F
+GLIBC_2.29 __dgettext F
+GLIBC_2.29 __dprintf_chk F
+GLIBC_2.29 __dup2 F
+GLIBC_2.29 __duplocale F
+GLIBC_2.29 __endmntent F
+GLIBC_2.29 __environ D 0x4
+GLIBC_2.29 __errno_location F
+GLIBC_2.29 __explicit_bzero_chk F
+GLIBC_2.29 __fbufsize F
+GLIBC_2.29 __fcntl F
+GLIBC_2.29 __fdelt_chk F
+GLIBC_2.29 __fdelt_warn F
+GLIBC_2.29 __ffs F
+GLIBC_2.29 __fgets_chk F
+GLIBC_2.29 __fgets_unlocked_chk F
+GLIBC_2.29 __fgetws_chk F
+GLIBC_2.29 __fgetws_unlocked_chk F
+GLIBC_2.29 __finite F
+GLIBC_2.29 __finitef F
+GLIBC_2.29 __finitel F
+GLIBC_2.29 __flbf F
+GLIBC_2.29 __fork F
+GLIBC_2.29 __fpending F
+GLIBC_2.29 __fprintf_chk F
+GLIBC_2.29 __fpu_control D 0x4
+GLIBC_2.29 __fpurge F
+GLIBC_2.29 __fread_chk F
+GLIBC_2.29 __fread_unlocked_chk F
+GLIBC_2.29 __freadable F
+GLIBC_2.29 __freading F
+GLIBC_2.29 __free_hook D 0x4
+GLIBC_2.29 __freelocale F
+GLIBC_2.29 __fsetlocking F
+GLIBC_2.29 __fwprintf_chk F
+GLIBC_2.29 __fwritable F
+GLIBC_2.29 __fwriting F
+GLIBC_2.29 __fxstat F
+GLIBC_2.29 __fxstat64 F
+GLIBC_2.29 __fxstatat F
+GLIBC_2.29 __fxstatat64 F
+GLIBC_2.29 __getauxval F
+GLIBC_2.29 __getcwd_chk F
+GLIBC_2.29 __getdelim F
+GLIBC_2.29 __getdomainname_chk F
+GLIBC_2.29 __getgroups_chk F
+GLIBC_2.29 __gethostname_chk F
+GLIBC_2.29 __getlogin_r_chk F
+GLIBC_2.29 __getmntent_r F
+GLIBC_2.29 __getpagesize F
+GLIBC_2.29 __getpgid F
+GLIBC_2.29 __getpid F
+GLIBC_2.29 __gets_chk F
+GLIBC_2.29 __gettimeofday F
+GLIBC_2.29 __getwd_chk F
+GLIBC_2.29 __gmtime_r F
+GLIBC_2.29 __h_errno_location F
+GLIBC_2.29 __isalnum_l F
+GLIBC_2.29 __isalpha_l F
+GLIBC_2.29 __isascii_l F
+GLIBC_2.29 __isblank_l F
+GLIBC_2.29 __iscntrl_l F
+GLIBC_2.29 __isctype F
+GLIBC_2.29 __isdigit_l F
+GLIBC_2.29 __isgraph_l F
+GLIBC_2.29 __isinf F
+GLIBC_2.29 __isinff F
+GLIBC_2.29 __isinfl F
+GLIBC_2.29 __islower_l F
+GLIBC_2.29 __isnan F
+GLIBC_2.29 __isnanf F
+GLIBC_2.29 __isnanl F
+GLIBC_2.29 __isoc99_fscanf F
+GLIBC_2.29 __isoc99_fwscanf F
+GLIBC_2.29 __isoc99_scanf F
+GLIBC_2.29 __isoc99_sscanf F
+GLIBC_2.29 __isoc99_swscanf F
+GLIBC_2.29 __isoc99_vfscanf F
+GLIBC_2.29 __isoc99_vfwscanf F
+GLIBC_2.29 __isoc99_vscanf F
+GLIBC_2.29 __isoc99_vsscanf F
+GLIBC_2.29 __isoc99_vswscanf F
+GLIBC_2.29 __isoc99_vwscanf F
+GLIBC_2.29 __isoc99_wscanf F
+GLIBC_2.29 __isprint_l F
+GLIBC_2.29 __ispunct_l F
+GLIBC_2.29 __isspace_l F
+GLIBC_2.29 __isupper_l F
+GLIBC_2.29 __iswalnum_l F
+GLIBC_2.29 __iswalpha_l F
+GLIBC_2.29 __iswblank_l F
+GLIBC_2.29 __iswcntrl_l F
+GLIBC_2.29 __iswctype F
+GLIBC_2.29 __iswctype_l F
+GLIBC_2.29 __iswdigit_l F
+GLIBC_2.29 __iswgraph_l F
+GLIBC_2.29 __iswlower_l F
+GLIBC_2.29 __iswprint_l F
+GLIBC_2.29 __iswpunct_l F
+GLIBC_2.29 __iswspace_l F
+GLIBC_2.29 __iswupper_l F
+GLIBC_2.29 __iswxdigit_l F
+GLIBC_2.29 __isxdigit_l F
+GLIBC_2.29 __ivaliduser F
+GLIBC_2.29 __key_decryptsession_pk_LOCAL D 0x4
+GLIBC_2.29 __key_encryptsession_pk_LOCAL D 0x4
+GLIBC_2.29 __key_gendes_LOCAL D 0x4
+GLIBC_2.29 __libc_allocate_rtsig F
+GLIBC_2.29 __libc_calloc F
+GLIBC_2.29 __libc_current_sigrtmax F
+GLIBC_2.29 __libc_current_sigrtmin F
+GLIBC_2.29 __libc_free F
+GLIBC_2.29 __libc_freeres F
+GLIBC_2.29 __libc_init_first F
+GLIBC_2.29 __libc_mallinfo F
+GLIBC_2.29 __libc_malloc F
+GLIBC_2.29 __libc_mallopt F
+GLIBC_2.29 __libc_memalign F
+GLIBC_2.29 __libc_pvalloc F
+GLIBC_2.29 __libc_realloc F
+GLIBC_2.29 __libc_sa_len F
+GLIBC_2.29 __libc_start_main F
+GLIBC_2.29 __libc_valloc F
+GLIBC_2.29 __longjmp_chk F
+GLIBC_2.29 __lseek F
+GLIBC_2.29 __lxstat F
+GLIBC_2.29 __lxstat64 F
+GLIBC_2.29 __malloc_hook D 0x4
+GLIBC_2.29 __mbrlen F
+GLIBC_2.29 __mbrtowc F
+GLIBC_2.29 __mbsnrtowcs_chk F
+GLIBC_2.29 __mbsrtowcs_chk F
+GLIBC_2.29 __mbstowcs_chk F
+GLIBC_2.29 __memalign_hook D 0x4
+GLIBC_2.29 __memcpy_chk F
+GLIBC_2.29 __memmove_chk F
+GLIBC_2.29 __mempcpy F
+GLIBC_2.29 __mempcpy_chk F
+GLIBC_2.29 __memset_chk F
+GLIBC_2.29 __monstartup F
+GLIBC_2.29 __morecore D 0x4
+GLIBC_2.29 __nanosleep F
+GLIBC_2.29 __newlocale F
+GLIBC_2.29 __nl_langinfo_l F
+GLIBC_2.29 __nss_configure_lookup F
+GLIBC_2.29 __nss_database_lookup F
+GLIBC_2.29 __nss_hostname_digits_dots F
+GLIBC_2.29 __nss_next F
+GLIBC_2.29 __obstack_printf_chk F
+GLIBC_2.29 __obstack_vprintf_chk F
+GLIBC_2.29 __open F
+GLIBC_2.29 __open64 F
+GLIBC_2.29 __open64_2 F
+GLIBC_2.29 __open_2 F
+GLIBC_2.29 __openat64_2 F
+GLIBC_2.29 __openat_2 F
+GLIBC_2.29 __overflow F
+GLIBC_2.29 __pipe F
+GLIBC_2.29 __poll F
+GLIBC_2.29 __poll_chk F
+GLIBC_2.29 __posix_getopt F
+GLIBC_2.29 __ppoll_chk F
+GLIBC_2.29 __pread64 F
+GLIBC_2.29 __pread64_chk F
+GLIBC_2.29 __pread_chk F
+GLIBC_2.29 __printf_chk F
+GLIBC_2.29 __printf_fp F
+GLIBC_2.29 __profile_frequency F
+GLIBC_2.29 __progname D 0x4
+GLIBC_2.29 __progname_full D 0x4
+GLIBC_2.29 __ptsname_r_chk F
+GLIBC_2.29 __pwrite64 F
+GLIBC_2.29 __rawmemchr F
+GLIBC_2.29 __rcmd_errstr D 0x4
+GLIBC_2.29 __read F
+GLIBC_2.29 __read_chk F
+GLIBC_2.29 __readlink_chk F
+GLIBC_2.29 __readlinkat_chk F
+GLIBC_2.29 __realloc_hook D 0x4
+GLIBC_2.29 __realpath_chk F
+GLIBC_2.29 __recv_chk F
+GLIBC_2.29 __recvfrom_chk F
+GLIBC_2.29 __register_atfork F
+GLIBC_2.29 __res_init F
+GLIBC_2.29 __res_nclose F
+GLIBC_2.29 __res_ninit F
+GLIBC_2.29 __res_randomid F
+GLIBC_2.29 __res_state F
+GLIBC_2.29 __riscv_flush_icache F
+GLIBC_2.29 __rpc_thread_createerr F
+GLIBC_2.29 __rpc_thread_svc_fdset F
+GLIBC_2.29 __rpc_thread_svc_max_pollfd F
+GLIBC_2.29 __rpc_thread_svc_pollfd F
+GLIBC_2.29 __sbrk F
+GLIBC_2.29 __sched_cpualloc F
+GLIBC_2.29 __sched_cpucount F
+GLIBC_2.29 __sched_cpufree F
+GLIBC_2.29 __sched_get_priority_max F
+GLIBC_2.29 __sched_get_priority_min F
+GLIBC_2.29 __sched_getparam F
+GLIBC_2.29 __sched_getscheduler F
+GLIBC_2.29 __sched_setscheduler F
+GLIBC_2.29 __sched_yield F
+GLIBC_2.29 __select F
+GLIBC_2.29 __send F
+GLIBC_2.29 __setmntent F
+GLIBC_2.29 __setpgid F
+GLIBC_2.29 __sigaction F
+GLIBC_2.29 __signbit F
+GLIBC_2.29 __signbitf F
+GLIBC_2.29 __signbitl F
+GLIBC_2.29 __sigpause F
+GLIBC_2.29 __sigsetjmp F
+GLIBC_2.29 __sigsuspend F
+GLIBC_2.29 __snprintf_chk F
+GLIBC_2.29 __sprintf_chk F
+GLIBC_2.29 __stack_chk_fail F
+GLIBC_2.29 __statfs F
+GLIBC_2.29 __stpcpy F
+GLIBC_2.29 __stpcpy_chk F
+GLIBC_2.29 __stpncpy F
+GLIBC_2.29 __stpncpy_chk F
+GLIBC_2.29 __strcasecmp F
+GLIBC_2.29 __strcasecmp_l F
+GLIBC_2.29 __strcasestr F
+GLIBC_2.29 __strcat_chk F
+GLIBC_2.29 __strcoll_l F
+GLIBC_2.29 __strcpy_chk F
+GLIBC_2.29 __strdup F
+GLIBC_2.29 __strerror_r F
+GLIBC_2.29 __strfmon_l F
+GLIBC_2.29 __strftime_l F
+GLIBC_2.29 __strncasecmp_l F
+GLIBC_2.29 __strncat_chk F
+GLIBC_2.29 __strncpy_chk F
+GLIBC_2.29 __strndup F
+GLIBC_2.29 __strsep_g F
+GLIBC_2.29 __strtod_internal F
+GLIBC_2.29 __strtod_l F
+GLIBC_2.29 __strtof_internal F
+GLIBC_2.29 __strtof_l F
+GLIBC_2.29 __strtok_r F
+GLIBC_2.29 __strtol_internal F
+GLIBC_2.29 __strtol_l F
+GLIBC_2.29 __strtold_internal F
+GLIBC_2.29 __strtold_l F
+GLIBC_2.29 __strtoll_internal F
+GLIBC_2.29 __strtoll_l F
+GLIBC_2.29 __strtoul_internal F
+GLIBC_2.29 __strtoul_l F
+GLIBC_2.29 __strtoull_internal F
+GLIBC_2.29 __strtoull_l F
+GLIBC_2.29 __strverscmp F
+GLIBC_2.29 __strxfrm_l F
+GLIBC_2.29 __swprintf_chk F
+GLIBC_2.29 __sysconf F
+GLIBC_2.29 __syslog_chk F
+GLIBC_2.29 __sysv_signal F
+GLIBC_2.29 __timezone D 0x4
+GLIBC_2.29 __toascii_l F
+GLIBC_2.29 __tolower_l F
+GLIBC_2.29 __toupper_l F
+GLIBC_2.29 __towctrans F
+GLIBC_2.29 __towctrans_l F
+GLIBC_2.29 __towlower_l F
+GLIBC_2.29 __towupper_l F
+GLIBC_2.29 __ttyname_r_chk F
+GLIBC_2.29 __tzname D 0x8
+GLIBC_2.29 __uflow F
+GLIBC_2.29 __underflow F
+GLIBC_2.29 __uselocale F
+GLIBC_2.29 __vasprintf_chk F
+GLIBC_2.29 __vdprintf_chk F
+GLIBC_2.29 __vfork F
+GLIBC_2.29 __vfprintf_chk F
+GLIBC_2.29 __vfscanf F
+GLIBC_2.29 __vfwprintf_chk F
+GLIBC_2.29 __vprintf_chk F
+GLIBC_2.29 __vsnprintf F
+GLIBC_2.29 __vsnprintf_chk F
+GLIBC_2.29 __vsprintf_chk F
+GLIBC_2.29 __vsscanf F
+GLIBC_2.29 __vswprintf_chk F
+GLIBC_2.29 __vsyslog_chk F
+GLIBC_2.29 __vwprintf_chk F
+GLIBC_2.29 __wait F
+GLIBC_2.29 __waitpid F
+GLIBC_2.29 __wcpcpy_chk F
+GLIBC_2.29 __wcpncpy_chk F
+GLIBC_2.29 __wcrtomb_chk F
+GLIBC_2.29 __wcscasecmp_l F
+GLIBC_2.29 __wcscat_chk F
+GLIBC_2.29 __wcscoll_l F
+GLIBC_2.29 __wcscpy_chk F
+GLIBC_2.29 __wcsftime_l F
+GLIBC_2.29 __wcsncasecmp_l F
+GLIBC_2.29 __wcsncat_chk F
+GLIBC_2.29 __wcsncpy_chk F
+GLIBC_2.29 __wcsnrtombs_chk F
+GLIBC_2.29 __wcsrtombs_chk F
+GLIBC_2.29 __wcstod_internal F
+GLIBC_2.29 __wcstod_l F
+GLIBC_2.29 __wcstof_internal F
+GLIBC_2.29 __wcstof_l F
+GLIBC_2.29 __wcstol_internal F
+GLIBC_2.29 __wcstol_l F
+GLIBC_2.29 __wcstold_internal F
+GLIBC_2.29 __wcstold_l F
+GLIBC_2.29 __wcstoll_internal F
+GLIBC_2.29 __wcstoll_l F
+GLIBC_2.29 __wcstombs_chk F
+GLIBC_2.29 __wcstoul_internal F
+GLIBC_2.29 __wcstoul_l F
+GLIBC_2.29 __wcstoull_internal F
+GLIBC_2.29 __wcstoull_l F
+GLIBC_2.29 __wcsxfrm_l F
+GLIBC_2.29 __wctomb_chk F
+GLIBC_2.29 __wctrans_l F
+GLIBC_2.29 __wctype_l F
+GLIBC_2.29 __wmemcpy_chk F
+GLIBC_2.29 __wmemmove_chk F
+GLIBC_2.29 __wmempcpy_chk F
+GLIBC_2.29 __wmemset_chk F
+GLIBC_2.29 __woverflow F
+GLIBC_2.29 __wprintf_chk F
+GLIBC_2.29 __write F
+GLIBC_2.29 __wuflow F
+GLIBC_2.29 __wunderflow F
+GLIBC_2.29 __xmknod F
+GLIBC_2.29 __xmknodat F
+GLIBC_2.29 __xpg_basename F
+GLIBC_2.29 __xpg_sigpause F
+GLIBC_2.29 __xpg_strerror_r F
+GLIBC_2.29 __xstat F
+GLIBC_2.29 __xstat64 F
+GLIBC_2.29 _authenticate F
+GLIBC_2.29 _dl_mcount_wrapper F
+GLIBC_2.29 _dl_mcount_wrapper_check F
+GLIBC_2.29 _environ D 0x4
+GLIBC_2.29 _exit F
+GLIBC_2.29 _flushlbf F
+GLIBC_2.29 _libc_intl_domainname D 0x5
+GLIBC_2.29 _longjmp F
+GLIBC_2.29 _mcleanup F
+GLIBC_2.29 _mcount F
+GLIBC_2.29 _nl_default_dirname D 0x12
+GLIBC_2.29 _nl_domain_bindings D 0x4
+GLIBC_2.29 _nl_msg_cat_cntr D 0x4
+GLIBC_2.29 _null_auth D 0xc
+GLIBC_2.29 _obstack_allocated_p F
+GLIBC_2.29 _obstack_begin F
+GLIBC_2.29 _obstack_begin_1 F
+GLIBC_2.29 _obstack_free F
+GLIBC_2.29 _obstack_memory_used F
+GLIBC_2.29 _obstack_newchunk F
+GLIBC_2.29 _res D 0x200
+GLIBC_2.29 _res_hconf D 0x30
+GLIBC_2.29 _rpc_dtablesize F
+GLIBC_2.29 _seterr_reply F
+GLIBC_2.29 _setjmp F
+GLIBC_2.29 _sys_errlist D 0x21c
+GLIBC_2.29 _sys_nerr D 0x4
+GLIBC_2.29 _sys_siglist D 0x104
+GLIBC_2.29 _tolower F
+GLIBC_2.29 _toupper F
+GLIBC_2.29 a64l F
+GLIBC_2.29 abort F
+GLIBC_2.29 abs F
+GLIBC_2.29 accept F
+GLIBC_2.29 accept4 F
+GLIBC_2.29 access F
+GLIBC_2.29 acct F
+GLIBC_2.29 addmntent F
+GLIBC_2.29 addseverity F
+GLIBC_2.29 adjtime F
+GLIBC_2.29 adjtimex F
+GLIBC_2.29 alarm F
+GLIBC_2.29 aligned_alloc F
+GLIBC_2.29 alphasort F
+GLIBC_2.29 alphasort64 F
+GLIBC_2.29 argp_err_exit_status D 0x4
+GLIBC_2.29 argp_error F
+GLIBC_2.29 argp_failure F
+GLIBC_2.29 argp_help F
+GLIBC_2.29 argp_parse F
+GLIBC_2.29 argp_program_bug_address D 0x4
+GLIBC_2.29 argp_program_version D 0x4
+GLIBC_2.29 argp_program_version_hook D 0x4
+GLIBC_2.29 argp_state_help F
+GLIBC_2.29 argp_usage F
+GLIBC_2.29 argz_add F
+GLIBC_2.29 argz_add_sep F
+GLIBC_2.29 argz_append F
+GLIBC_2.29 argz_count F
+GLIBC_2.29 argz_create F
+GLIBC_2.29 argz_create_sep F
+GLIBC_2.29 argz_delete F
+GLIBC_2.29 argz_extract F
+GLIBC_2.29 argz_insert F
+GLIBC_2.29 argz_next F
+GLIBC_2.29 argz_replace F
+GLIBC_2.29 argz_stringify F
+GLIBC_2.29 asctime F
+GLIBC_2.29 asctime_r F
+GLIBC_2.29 asprintf F
+GLIBC_2.29 atof F
+GLIBC_2.29 atoi F
+GLIBC_2.29 atol F
+GLIBC_2.29 atoll F
+GLIBC_2.29 authdes_create F
+GLIBC_2.29 authdes_getucred F
+GLIBC_2.29 authdes_pk_create F
+GLIBC_2.29 authnone_create F
+GLIBC_2.29 authunix_create F
+GLIBC_2.29 authunix_create_default F
+GLIBC_2.29 backtrace F
+GLIBC_2.29 backtrace_symbols F
+GLIBC_2.29 backtrace_symbols_fd F
+GLIBC_2.29 basename F
+GLIBC_2.29 bcmp F
+GLIBC_2.29 bcopy F
+GLIBC_2.29 bind F
+GLIBC_2.29 bind_textdomain_codeset F
+GLIBC_2.29 bindresvport F
+GLIBC_2.29 bindtextdomain F
+GLIBC_2.29 brk F
+GLIBC_2.29 bsd_signal F
+GLIBC_2.29 bsearch F
+GLIBC_2.29 btowc F
+GLIBC_2.29 bzero F
+GLIBC_2.29 c16rtomb F
+GLIBC_2.29 c32rtomb F
+GLIBC_2.29 calloc F
+GLIBC_2.29 callrpc F
+GLIBC_2.29 canonicalize_file_name F
+GLIBC_2.29 capget F
+GLIBC_2.29 capset F
+GLIBC_2.29 catclose F
+GLIBC_2.29 catgets F
+GLIBC_2.29 catopen F
+GLIBC_2.29 cbc_crypt F
+GLIBC_2.29 cfgetispeed F
+GLIBC_2.29 cfgetospeed F
+GLIBC_2.29 cfmakeraw F
+GLIBC_2.29 cfsetispeed F
+GLIBC_2.29 cfsetospeed F
+GLIBC_2.29 cfsetspeed F
+GLIBC_2.29 chdir F
+GLIBC_2.29 chflags F
+GLIBC_2.29 chmod F
+GLIBC_2.29 chown F
+GLIBC_2.29 chroot F
+GLIBC_2.29 clearenv F
+GLIBC_2.29 clearerr F
+GLIBC_2.29 clearerr_unlocked F
+GLIBC_2.29 clnt_broadcast F
+GLIBC_2.29 clnt_create F
+GLIBC_2.29 clnt_pcreateerror F
+GLIBC_2.29 clnt_perrno F
+GLIBC_2.29 clnt_perror F
+GLIBC_2.29 clnt_spcreateerror F
+GLIBC_2.29 clnt_sperrno F
+GLIBC_2.29 clnt_sperror F
+GLIBC_2.29 clntraw_create F
+GLIBC_2.29 clnttcp_create F
+GLIBC_2.29 clntudp_bufcreate F
+GLIBC_2.29 clntudp_create F
+GLIBC_2.29 clntunix_create F
+GLIBC_2.29 clock F
+GLIBC_2.29 clock_adjtime F
+GLIBC_2.29 clock_getcpuclockid F
+GLIBC_2.29 clock_getres F
+GLIBC_2.29 clock_gettime F
+GLIBC_2.29 clock_nanosleep F
+GLIBC_2.29 clock_settime F
+GLIBC_2.29 clone F
+GLIBC_2.29 close F
+GLIBC_2.29 closedir F
+GLIBC_2.29 closelog F
+GLIBC_2.29 confstr F
+GLIBC_2.29 connect F
+GLIBC_2.29 copy_file_range F
+GLIBC_2.29 copysign F
+GLIBC_2.29 copysignf F
+GLIBC_2.29 copysignl F
+GLIBC_2.29 creat F
+GLIBC_2.29 creat64 F
+GLIBC_2.29 ctermid F
+GLIBC_2.29 ctime F
+GLIBC_2.29 ctime_r F
+GLIBC_2.29 cuserid F
+GLIBC_2.29 daemon F
+GLIBC_2.29 daylight D 0x4
+GLIBC_2.29 dcgettext F
+GLIBC_2.29 dcngettext F
+GLIBC_2.29 delete_module F
+GLIBC_2.29 des_setparity F
+GLIBC_2.29 dgettext F
+GLIBC_2.29 difftime F
+GLIBC_2.29 dirfd F
+GLIBC_2.29 dirname F
+GLIBC_2.29 div F
+GLIBC_2.29 dl_iterate_phdr F
+GLIBC_2.29 dngettext F
+GLIBC_2.29 dprintf F
+GLIBC_2.29 drand48 F
+GLIBC_2.29 drand48_r F
+GLIBC_2.29 dup F
+GLIBC_2.29 dup2 F
+GLIBC_2.29 dup3 F
+GLIBC_2.29 duplocale F
+GLIBC_2.29 dysize F
+GLIBC_2.29 eaccess F
+GLIBC_2.29 ecb_crypt F
+GLIBC_2.29 ecvt F
+GLIBC_2.29 ecvt_r F
+GLIBC_2.29 endaliasent F
+GLIBC_2.29 endfsent F
+GLIBC_2.29 endgrent F
+GLIBC_2.29 endhostent F
+GLIBC_2.29 endmntent F
+GLIBC_2.29 endnetent F
+GLIBC_2.29 endnetgrent F
+GLIBC_2.29 endprotoent F
+GLIBC_2.29 endpwent F
+GLIBC_2.29 endrpcent F
+GLIBC_2.29 endservent F
+GLIBC_2.29 endsgent F
+GLIBC_2.29 endspent F
+GLIBC_2.29 endttyent F
+GLIBC_2.29 endusershell F
+GLIBC_2.29 endutent F
+GLIBC_2.29 endutxent F
+GLIBC_2.29 environ D 0x4
+GLIBC_2.29 envz_add F
+GLIBC_2.29 envz_entry F
+GLIBC_2.29 envz_get F
+GLIBC_2.29 envz_merge F
+GLIBC_2.29 envz_remove F
+GLIBC_2.29 envz_strip F
+GLIBC_2.29 epoll_create F
+GLIBC_2.29 epoll_create1 F
+GLIBC_2.29 epoll_ctl F
+GLIBC_2.29 epoll_pwait F
+GLIBC_2.29 epoll_wait F
+GLIBC_2.29 erand48 F
+GLIBC_2.29 erand48_r F
+GLIBC_2.29 err F
+GLIBC_2.29 error F
+GLIBC_2.29 error_at_line F
+GLIBC_2.29 error_message_count D 0x4
+GLIBC_2.29 error_one_per_line D 0x4
+GLIBC_2.29 error_print_progname D 0x4
+GLIBC_2.29 errx F
+GLIBC_2.29 ether_aton F
+GLIBC_2.29 ether_aton_r F
+GLIBC_2.29 ether_hostton F
+GLIBC_2.29 ether_line F
+GLIBC_2.29 ether_ntoa F
+GLIBC_2.29 ether_ntoa_r F
+GLIBC_2.29 ether_ntohost F
+GLIBC_2.29 euidaccess F
+GLIBC_2.29 eventfd F
+GLIBC_2.29 eventfd_read F
+GLIBC_2.29 eventfd_write F
+GLIBC_2.29 execl F
+GLIBC_2.29 execle F
+GLIBC_2.29 execlp F
+GLIBC_2.29 execv F
+GLIBC_2.29 execve F
+GLIBC_2.29 execvp F
+GLIBC_2.29 execvpe F
+GLIBC_2.29 exit F
+GLIBC_2.29 explicit_bzero F
+GLIBC_2.29 faccessat F
+GLIBC_2.29 fallocate F
+GLIBC_2.29 fallocate64 F
+GLIBC_2.29 fanotify_init F
+GLIBC_2.29 fanotify_mark F
+GLIBC_2.29 fattach F
+GLIBC_2.29 fchdir F
+GLIBC_2.29 fchflags F
+GLIBC_2.29 fchmod F
+GLIBC_2.29 fchmodat F
+GLIBC_2.29 fchown F
+GLIBC_2.29 fchownat F
+GLIBC_2.29 fclose F
+GLIBC_2.29 fcloseall F
+GLIBC_2.29 fcntl F
+GLIBC_2.29 fcntl64 F
+GLIBC_2.29 fcvt F
+GLIBC_2.29 fcvt_r F
+GLIBC_2.29 fdatasync F
+GLIBC_2.29 fdetach F
+GLIBC_2.29 fdopen F
+GLIBC_2.29 fdopendir F
+GLIBC_2.29 feof F
+GLIBC_2.29 feof_unlocked F
+GLIBC_2.29 ferror F
+GLIBC_2.29 ferror_unlocked F
+GLIBC_2.29 fexecve F
+GLIBC_2.29 fflush F
+GLIBC_2.29 fflush_unlocked F
+GLIBC_2.29 ffs F
+GLIBC_2.29 ffsl F
+GLIBC_2.29 ffsll F
+GLIBC_2.29 fgetc F
+GLIBC_2.29 fgetc_unlocked F
+GLIBC_2.29 fgetgrent F
+GLIBC_2.29 fgetgrent_r F
+GLIBC_2.29 fgetpos F
+GLIBC_2.29 fgetpos64 F
+GLIBC_2.29 fgetpwent F
+GLIBC_2.29 fgetpwent_r F
+GLIBC_2.29 fgets F
+GLIBC_2.29 fgets_unlocked F
+GLIBC_2.29 fgetsgent F
+GLIBC_2.29 fgetsgent_r F
+GLIBC_2.29 fgetspent F
+GLIBC_2.29 fgetspent_r F
+GLIBC_2.29 fgetwc F
+GLIBC_2.29 fgetwc_unlocked F
+GLIBC_2.29 fgetws F
+GLIBC_2.29 fgetws_unlocked F
+GLIBC_2.29 fgetxattr F
+GLIBC_2.29 fileno F
+GLIBC_2.29 fileno_unlocked F
+GLIBC_2.29 finite F
+GLIBC_2.29 finitef F
+GLIBC_2.29 finitel F
+GLIBC_2.29 flistxattr F
+GLIBC_2.29 flock F
+GLIBC_2.29 flockfile F
+GLIBC_2.29 fmemopen F
+GLIBC_2.29 fmtmsg F
+GLIBC_2.29 fnmatch F
+GLIBC_2.29 fopen F
+GLIBC_2.29 fopen64 F
+GLIBC_2.29 fopencookie F
+GLIBC_2.29 fork F
+GLIBC_2.29 fpathconf F
+GLIBC_2.29 fprintf F
+GLIBC_2.29 fputc F
+GLIBC_2.29 fputc_unlocked F
+GLIBC_2.29 fputs F
+GLIBC_2.29 fputs_unlocked F
+GLIBC_2.29 fputwc F
+GLIBC_2.29 fputwc_unlocked F
+GLIBC_2.29 fputws F
+GLIBC_2.29 fputws_unlocked F
+GLIBC_2.29 fread F
+GLIBC_2.29 fread_unlocked F
+GLIBC_2.29 free F
+GLIBC_2.29 freeaddrinfo F
+GLIBC_2.29 freeifaddrs F
+GLIBC_2.29 freelocale F
+GLIBC_2.29 fremovexattr F
+GLIBC_2.29 freopen F
+GLIBC_2.29 freopen64 F
+GLIBC_2.29 frexp F
+GLIBC_2.29 frexpf F
+GLIBC_2.29 frexpl F
+GLIBC_2.29 fscanf F
+GLIBC_2.29 fseek F
+GLIBC_2.29 fseeko F
+GLIBC_2.29 fseeko64 F
+GLIBC_2.29 fsetpos F
+GLIBC_2.29 fsetpos64 F
+GLIBC_2.29 fsetxattr F
+GLIBC_2.29 fstatfs F
+GLIBC_2.29 fstatfs64 F
+GLIBC_2.29 fstatvfs F
+GLIBC_2.29 fstatvfs64 F
+GLIBC_2.29 fsync F
+GLIBC_2.29 ftell F
+GLIBC_2.29 ftello F
+GLIBC_2.29 ftello64 F
+GLIBC_2.29 ftime F
+GLIBC_2.29 ftok F
+GLIBC_2.29 ftruncate F
+GLIBC_2.29 ftruncate64 F
+GLIBC_2.29 ftrylockfile F
+GLIBC_2.29 fts64_children F
+GLIBC_2.29 fts64_close F
+GLIBC_2.29 fts64_open F
+GLIBC_2.29 fts64_read F
+GLIBC_2.29 fts64_set F
+GLIBC_2.29 fts_children F
+GLIBC_2.29 fts_close F
+GLIBC_2.29 fts_open F
+GLIBC_2.29 fts_read F
+GLIBC_2.29 fts_set F
+GLIBC_2.29 ftw F
+GLIBC_2.29 ftw64 F
+GLIBC_2.29 funlockfile F
+GLIBC_2.29 futimens F
+GLIBC_2.29 futimes F
+GLIBC_2.29 futimesat F
+GLIBC_2.29 fwide F
+GLIBC_2.29 fwprintf F
+GLIBC_2.29 fwrite F
+GLIBC_2.29 fwrite_unlocked F
+GLIBC_2.29 fwscanf F
+GLIBC_2.29 gai_strerror F
+GLIBC_2.29 gcvt F
+GLIBC_2.29 get_avphys_pages F
+GLIBC_2.29 get_current_dir_name F
+GLIBC_2.29 get_myaddress F
+GLIBC_2.29 get_nprocs F
+GLIBC_2.29 get_nprocs_conf F
+GLIBC_2.29 get_phys_pages F
+GLIBC_2.29 getaddrinfo F
+GLIBC_2.29 getaliasbyname F
+GLIBC_2.29 getaliasbyname_r F
+GLIBC_2.29 getaliasent F
+GLIBC_2.29 getaliasent_r F
+GLIBC_2.29 getauxval F
+GLIBC_2.29 getc F
+GLIBC_2.29 getc_unlocked F
+GLIBC_2.29 getchar F
+GLIBC_2.29 getchar_unlocked F
+GLIBC_2.29 getcontext F
+GLIBC_2.29 getcpu F
+GLIBC_2.29 getcwd F
+GLIBC_2.29 getdate F
+GLIBC_2.29 getdate_err D 0x4
+GLIBC_2.29 getdate_r F
+GLIBC_2.29 getdelim F
+GLIBC_2.29 getdirentries F
+GLIBC_2.29 getdirentries64 F
+GLIBC_2.29 getdomainname F
+GLIBC_2.29 getdtablesize F
+GLIBC_2.29 getegid F
+GLIBC_2.29 getentropy F
+GLIBC_2.29 getenv F
+GLIBC_2.29 geteuid F
+GLIBC_2.29 getfsent F
+GLIBC_2.29 getfsfile F
+GLIBC_2.29 getfsspec F
+GLIBC_2.29 getgid F
+GLIBC_2.29 getgrent F
+GLIBC_2.29 getgrent_r F
+GLIBC_2.29 getgrgid F
+GLIBC_2.29 getgrgid_r F
+GLIBC_2.29 getgrnam F
+GLIBC_2.29 getgrnam_r F
+GLIBC_2.29 getgrouplist F
+GLIBC_2.29 getgroups F
+GLIBC_2.29 gethostbyaddr F
+GLIBC_2.29 gethostbyaddr_r F
+GLIBC_2.29 gethostbyname F
+GLIBC_2.29 gethostbyname2 F
+GLIBC_2.29 gethostbyname2_r F
+GLIBC_2.29 gethostbyname_r F
+GLIBC_2.29 gethostent F
+GLIBC_2.29 gethostent_r F
+GLIBC_2.29 gethostid F
+GLIBC_2.29 gethostname F
+GLIBC_2.29 getifaddrs F
+GLIBC_2.29 getipv4sourcefilter F
+GLIBC_2.29 getitimer F
+GLIBC_2.29 getline F
+GLIBC_2.29 getloadavg F
+GLIBC_2.29 getlogin F
+GLIBC_2.29 getlogin_r F
+GLIBC_2.29 getmntent F
+GLIBC_2.29 getmntent_r F
+GLIBC_2.29 getmsg F
+GLIBC_2.29 getnameinfo F
+GLIBC_2.29 getnetbyaddr F
+GLIBC_2.29 getnetbyaddr_r F
+GLIBC_2.29 getnetbyname F
+GLIBC_2.29 getnetbyname_r F
+GLIBC_2.29 getnetent F
+GLIBC_2.29 getnetent_r F
+GLIBC_2.29 getnetgrent F
+GLIBC_2.29 getnetgrent_r F
+GLIBC_2.29 getnetname F
+GLIBC_2.29 getopt F
+GLIBC_2.29 getopt_long F
+GLIBC_2.29 getopt_long_only F
+GLIBC_2.29 getpagesize F
+GLIBC_2.29 getpass F
+GLIBC_2.29 getpeername F
+GLIBC_2.29 getpgid F
+GLIBC_2.29 getpgrp F
+GLIBC_2.29 getpid F
+GLIBC_2.29 getpmsg F
+GLIBC_2.29 getppid F
+GLIBC_2.29 getpriority F
+GLIBC_2.29 getprotobyname F
+GLIBC_2.29 getprotobyname_r F
+GLIBC_2.29 getprotobynumber F
+GLIBC_2.29 getprotobynumber_r F
+GLIBC_2.29 getprotoent F
+GLIBC_2.29 getprotoent_r F
+GLIBC_2.29 getpt F
+GLIBC_2.29 getpublickey F
+GLIBC_2.29 getpw F
+GLIBC_2.29 getpwent F
+GLIBC_2.29 getpwent_r F
+GLIBC_2.29 getpwnam F
+GLIBC_2.29 getpwnam_r F
+GLIBC_2.29 getpwuid F
+GLIBC_2.29 getpwuid_r F
+GLIBC_2.29 getrandom F
+GLIBC_2.29 getresgid F
+GLIBC_2.29 getresuid F
+GLIBC_2.29 getrlimit F
+GLIBC_2.29 getrlimit64 F
+GLIBC_2.29 getrpcbyname F
+GLIBC_2.29 getrpcbyname_r F
+GLIBC_2.29 getrpcbynumber F
+GLIBC_2.29 getrpcbynumber_r F
+GLIBC_2.29 getrpcent F
+GLIBC_2.29 getrpcent_r F
+GLIBC_2.29 getrpcport F
+GLIBC_2.29 getrusage F
+GLIBC_2.29 gets F
+GLIBC_2.29 getsecretkey F
+GLIBC_2.29 getservbyname F
+GLIBC_2.29 getservbyname_r F
+GLIBC_2.29 getservbyport F
+GLIBC_2.29 getservbyport_r F
+GLIBC_2.29 getservent F
+GLIBC_2.29 getservent_r F
+GLIBC_2.29 getsgent F
+GLIBC_2.29 getsgent_r F
+GLIBC_2.29 getsgnam F
+GLIBC_2.29 getsgnam_r F
+GLIBC_2.29 getsid F
+GLIBC_2.29 getsockname F
+GLIBC_2.29 getsockopt F
+GLIBC_2.29 getsourcefilter F
+GLIBC_2.29 getspent F
+GLIBC_2.29 getspent_r F
+GLIBC_2.29 getspnam F
+GLIBC_2.29 getspnam_r F
+GLIBC_2.29 getsubopt F
+GLIBC_2.29 gettext F
+GLIBC_2.29 gettimeofday F
+GLIBC_2.29 getttyent F
+GLIBC_2.29 getttynam F
+GLIBC_2.29 getuid F
+GLIBC_2.29 getusershell F
+GLIBC_2.29 getutent F
+GLIBC_2.29 getutent_r F
+GLIBC_2.29 getutid F
+GLIBC_2.29 getutid_r F
+GLIBC_2.29 getutline F
+GLIBC_2.29 getutline_r F
+GLIBC_2.29 getutmp F
+GLIBC_2.29 getutmpx F
+GLIBC_2.29 getutxent F
+GLIBC_2.29 getutxid F
+GLIBC_2.29 getutxline F
+GLIBC_2.29 getw F
+GLIBC_2.29 getwc F
+GLIBC_2.29 getwc_unlocked F
+GLIBC_2.29 getwchar F
+GLIBC_2.29 getwchar_unlocked F
+GLIBC_2.29 getwd F
+GLIBC_2.29 getxattr F
+GLIBC_2.29 glob F
+GLIBC_2.29 glob64 F
+GLIBC_2.29 glob_pattern_p F
+GLIBC_2.29 globfree F
+GLIBC_2.29 globfree64 F
+GLIBC_2.29 gmtime F
+GLIBC_2.29 gmtime_r F
+GLIBC_2.29 gnu_dev_major F
+GLIBC_2.29 gnu_dev_makedev F
+GLIBC_2.29 gnu_dev_minor F
+GLIBC_2.29 gnu_get_libc_release F
+GLIBC_2.29 gnu_get_libc_version F
+GLIBC_2.29 grantpt F
+GLIBC_2.29 group_member F
+GLIBC_2.29 gsignal F
+GLIBC_2.29 gtty F
+GLIBC_2.29 h_errlist D 0x14
+GLIBC_2.29 h_nerr D 0x4
+GLIBC_2.29 hasmntopt F
+GLIBC_2.29 hcreate F
+GLIBC_2.29 hcreate_r F
+GLIBC_2.29 hdestroy F
+GLIBC_2.29 hdestroy_r F
+GLIBC_2.29 herror F
+GLIBC_2.29 host2netname F
+GLIBC_2.29 hsearch F
+GLIBC_2.29 hsearch_r F
+GLIBC_2.29 hstrerror F
+GLIBC_2.29 htonl F
+GLIBC_2.29 htons F
+GLIBC_2.29 iconv F
+GLIBC_2.29 iconv_close F
+GLIBC_2.29 iconv_open F
+GLIBC_2.29 if_freenameindex F
+GLIBC_2.29 if_indextoname F
+GLIBC_2.29 if_nameindex F
+GLIBC_2.29 if_nametoindex F
+GLIBC_2.29 imaxabs F
+GLIBC_2.29 imaxdiv F
+GLIBC_2.29 in6addr_any D 0x10
+GLIBC_2.29 in6addr_loopback D 0x10
+GLIBC_2.29 index F
+GLIBC_2.29 inet6_opt_append F
+GLIBC_2.29 inet6_opt_find F
+GLIBC_2.29 inet6_opt_finish F
+GLIBC_2.29 inet6_opt_get_val F
+GLIBC_2.29 inet6_opt_init F
+GLIBC_2.29 inet6_opt_next F
+GLIBC_2.29 inet6_opt_set_val F
+GLIBC_2.29 inet6_option_alloc F
+GLIBC_2.29 inet6_option_append F
+GLIBC_2.29 inet6_option_find F
+GLIBC_2.29 inet6_option_init F
+GLIBC_2.29 inet6_option_next F
+GLIBC_2.29 inet6_option_space F
+GLIBC_2.29 inet6_rth_add F
+GLIBC_2.29 inet6_rth_getaddr F
+GLIBC_2.29 inet6_rth_init F
+GLIBC_2.29 inet6_rth_reverse F
+GLIBC_2.29 inet6_rth_segments F
+GLIBC_2.29 inet6_rth_space F
+GLIBC_2.29 inet_addr F
+GLIBC_2.29 inet_aton F
+GLIBC_2.29 inet_lnaof F
+GLIBC_2.29 inet_makeaddr F
+GLIBC_2.29 inet_netof F
+GLIBC_2.29 inet_network F
+GLIBC_2.29 inet_nsap_addr F
+GLIBC_2.29 inet_nsap_ntoa F
+GLIBC_2.29 inet_ntoa F
+GLIBC_2.29 inet_ntop F
+GLIBC_2.29 inet_pton F
+GLIBC_2.29 init_module F
+GLIBC_2.29 initgroups F
+GLIBC_2.29 initstate F
+GLIBC_2.29 initstate_r F
+GLIBC_2.29 innetgr F
+GLIBC_2.29 inotify_add_watch F
+GLIBC_2.29 inotify_init F
+GLIBC_2.29 inotify_init1 F
+GLIBC_2.29 inotify_rm_watch F
+GLIBC_2.29 insque F
+GLIBC_2.29 ioctl F
+GLIBC_2.29 iruserok F
+GLIBC_2.29 iruserok_af F
+GLIBC_2.29 isalnum F
+GLIBC_2.29 isalnum_l F
+GLIBC_2.29 isalpha F
+GLIBC_2.29 isalpha_l F
+GLIBC_2.29 isascii F
+GLIBC_2.29 isastream F
+GLIBC_2.29 isatty F
+GLIBC_2.29 isblank F
+GLIBC_2.29 isblank_l F
+GLIBC_2.29 iscntrl F
+GLIBC_2.29 iscntrl_l F
+GLIBC_2.29 isctype F
+GLIBC_2.29 isdigit F
+GLIBC_2.29 isdigit_l F
+GLIBC_2.29 isfdtype F
+GLIBC_2.29 isgraph F
+GLIBC_2.29 isgraph_l F
+GLIBC_2.29 isinf F
+GLIBC_2.29 isinff F
+GLIBC_2.29 isinfl F
+GLIBC_2.29 islower F
+GLIBC_2.29 islower_l F
+GLIBC_2.29 isnan F
+GLIBC_2.29 isnanf F
+GLIBC_2.29 isnanl F
+GLIBC_2.29 isprint F
+GLIBC_2.29 isprint_l F
+GLIBC_2.29 ispunct F
+GLIBC_2.29 ispunct_l F
+GLIBC_2.29 isspace F
+GLIBC_2.29 isspace_l F
+GLIBC_2.29 isupper F
+GLIBC_2.29 isupper_l F
+GLIBC_2.29 iswalnum F
+GLIBC_2.29 iswalnum_l F
+GLIBC_2.29 iswalpha F
+GLIBC_2.29 iswalpha_l F
+GLIBC_2.29 iswblank F
+GLIBC_2.29 iswblank_l F
+GLIBC_2.29 iswcntrl F
+GLIBC_2.29 iswcntrl_l F
+GLIBC_2.29 iswctype F
+GLIBC_2.29 iswctype_l F
+GLIBC_2.29 iswdigit F
+GLIBC_2.29 iswdigit_l F
+GLIBC_2.29 iswgraph F
+GLIBC_2.29 iswgraph_l F
+GLIBC_2.29 iswlower F
+GLIBC_2.29 iswlower_l F
+GLIBC_2.29 iswprint F
+GLIBC_2.29 iswprint_l F
+GLIBC_2.29 iswpunct F
+GLIBC_2.29 iswpunct_l F
+GLIBC_2.29 iswspace F
+GLIBC_2.29 iswspace_l F
+GLIBC_2.29 iswupper F
+GLIBC_2.29 iswupper_l F
+GLIBC_2.29 iswxdigit F
+GLIBC_2.29 iswxdigit_l F
+GLIBC_2.29 isxdigit F
+GLIBC_2.29 isxdigit_l F
+GLIBC_2.29 jrand48 F
+GLIBC_2.29 jrand48_r F
+GLIBC_2.29 key_decryptsession F
+GLIBC_2.29 key_decryptsession_pk F
+GLIBC_2.29 key_encryptsession F
+GLIBC_2.29 key_encryptsession_pk F
+GLIBC_2.29 key_gendes F
+GLIBC_2.29 key_get_conv F
+GLIBC_2.29 key_secretkey_is_set F
+GLIBC_2.29 key_setnet F
+GLIBC_2.29 key_setsecret F
+GLIBC_2.29 kill F
+GLIBC_2.29 killpg F
+GLIBC_2.29 klogctl F
+GLIBC_2.29 l64a F
+GLIBC_2.29 labs F
+GLIBC_2.29 lchmod F
+GLIBC_2.29 lchown F
+GLIBC_2.29 lckpwdf F
+GLIBC_2.29 lcong48 F
+GLIBC_2.29 lcong48_r F
+GLIBC_2.29 ldexp F
+GLIBC_2.29 ldexpf F
+GLIBC_2.29 ldexpl F
+GLIBC_2.29 ldiv F
+GLIBC_2.29 lfind F
+GLIBC_2.29 lgetxattr F
+GLIBC_2.29 link F
+GLIBC_2.29 linkat F
+GLIBC_2.29 listen F
+GLIBC_2.29 listxattr F
+GLIBC_2.29 llabs F
+GLIBC_2.29 lldiv F
+GLIBC_2.29 llistxattr F
+GLIBC_2.29 localeconv F
+GLIBC_2.29 localtime F
+GLIBC_2.29 localtime_r F
+GLIBC_2.29 lockf F
+GLIBC_2.29 lockf64 F
+GLIBC_2.29 longjmp F
+GLIBC_2.29 lrand48 F
+GLIBC_2.29 lrand48_r F
+GLIBC_2.29 lremovexattr F
+GLIBC_2.29 lsearch F
+GLIBC_2.29 lseek F
+GLIBC_2.29 lseek64 F
+GLIBC_2.29 lsetxattr F
+GLIBC_2.29 lutimes F
+GLIBC_2.29 madvise F
+GLIBC_2.29 makecontext F
+GLIBC_2.29 mallinfo F
+GLIBC_2.29 malloc F
+GLIBC_2.29 malloc_info F
+GLIBC_2.29 malloc_stats F
+GLIBC_2.29 malloc_trim F
+GLIBC_2.29 malloc_usable_size F
+GLIBC_2.29 mallopt F
+GLIBC_2.29 mallwatch D 0x4
+GLIBC_2.29 mblen F
+GLIBC_2.29 mbrlen F
+GLIBC_2.29 mbrtoc16 F
+GLIBC_2.29 mbrtoc32 F
+GLIBC_2.29 mbrtowc F
+GLIBC_2.29 mbsinit F
+GLIBC_2.29 mbsnrtowcs F
+GLIBC_2.29 mbsrtowcs F
+GLIBC_2.29 mbstowcs F
+GLIBC_2.29 mbtowc F
+GLIBC_2.29 mcheck F
+GLIBC_2.29 mcheck_check_all F
+GLIBC_2.29 mcheck_pedantic F
+GLIBC_2.29 memalign F
+GLIBC_2.29 memccpy F
+GLIBC_2.29 memchr F
+GLIBC_2.29 memcmp F
+GLIBC_2.29 memcpy F
+GLIBC_2.29 memfd_create F
+GLIBC_2.29 memfrob F
+GLIBC_2.29 memmem F
+GLIBC_2.29 memmove F
+GLIBC_2.29 mempcpy F
+GLIBC_2.29 memrchr F
+GLIBC_2.29 memset F
+GLIBC_2.29 mincore F
+GLIBC_2.29 mkdir F
+GLIBC_2.29 mkdirat F
+GLIBC_2.29 mkdtemp F
+GLIBC_2.29 mkfifo F
+GLIBC_2.29 mkfifoat F
+GLIBC_2.29 mkostemp F
+GLIBC_2.29 mkostemp64 F
+GLIBC_2.29 mkostemps F
+GLIBC_2.29 mkostemps64 F
+GLIBC_2.29 mkstemp F
+GLIBC_2.29 mkstemp64 F
+GLIBC_2.29 mkstemps F
+GLIBC_2.29 mkstemps64 F
+GLIBC_2.29 mktemp F
+GLIBC_2.29 mktime F
+GLIBC_2.29 mlock F
+GLIBC_2.29 mlock2 F
+GLIBC_2.29 mlockall F
+GLIBC_2.29 mmap F
+GLIBC_2.29 mmap64 F
+GLIBC_2.29 modf F
+GLIBC_2.29 modff F
+GLIBC_2.29 modfl F
+GLIBC_2.29 moncontrol F
+GLIBC_2.29 monstartup F
+GLIBC_2.29 mount F
+GLIBC_2.29 mprobe F
+GLIBC_2.29 mprotect F
+GLIBC_2.29 mrand48 F
+GLIBC_2.29 mrand48_r F
+GLIBC_2.29 mremap F
+GLIBC_2.29 msgctl F
+GLIBC_2.29 msgget F
+GLIBC_2.29 msgrcv F
+GLIBC_2.29 msgsnd F
+GLIBC_2.29 msync F
+GLIBC_2.29 mtrace F
+GLIBC_2.29 munlock F
+GLIBC_2.29 munlockall F
+GLIBC_2.29 munmap F
+GLIBC_2.29 muntrace F
+GLIBC_2.29 name_to_handle_at F
+GLIBC_2.29 nanosleep F
+GLIBC_2.29 netname2host F
+GLIBC_2.29 netname2user F
+GLIBC_2.29 newlocale F
+GLIBC_2.29 nftw F
+GLIBC_2.29 nftw64 F
+GLIBC_2.29 ngettext F
+GLIBC_2.29 nice F
+GLIBC_2.29 nl_langinfo F
+GLIBC_2.29 nl_langinfo_l F
+GLIBC_2.29 nrand48 F
+GLIBC_2.29 nrand48_r F
+GLIBC_2.29 ntohl F
+GLIBC_2.29 ntohs F
+GLIBC_2.29 ntp_adjtime F
+GLIBC_2.29 ntp_gettime F
+GLIBC_2.29 ntp_gettimex F
+GLIBC_2.29 obstack_alloc_failed_handler D 0x4
+GLIBC_2.29 obstack_exit_failure D 0x4
+GLIBC_2.29 obstack_free F
+GLIBC_2.29 obstack_printf F
+GLIBC_2.29 obstack_vprintf F
+GLIBC_2.29 on_exit F
+GLIBC_2.29 open F
+GLIBC_2.29 open64 F
+GLIBC_2.29 open_by_handle_at F
+GLIBC_2.29 open_memstream F
+GLIBC_2.29 open_wmemstream F
+GLIBC_2.29 openat F
+GLIBC_2.29 openat64 F
+GLIBC_2.29 opendir F
+GLIBC_2.29 openlog F
+GLIBC_2.29 optarg D 0x4
+GLIBC_2.29 opterr D 0x4
+GLIBC_2.29 optind D 0x4
+GLIBC_2.29 optopt D 0x4
+GLIBC_2.29 parse_printf_format F
+GLIBC_2.29 passwd2des F
+GLIBC_2.29 pathconf F
+GLIBC_2.29 pause F
+GLIBC_2.29 pclose F
+GLIBC_2.29 perror F
+GLIBC_2.29 personality F
+GLIBC_2.29 pipe F
+GLIBC_2.29 pipe2 F
+GLIBC_2.29 pivot_root F
+GLIBC_2.29 pkey_alloc F
+GLIBC_2.29 pkey_free F
+GLIBC_2.29 pkey_get F
+GLIBC_2.29 pkey_mprotect F
+GLIBC_2.29 pkey_set F
+GLIBC_2.29 pmap_getmaps F
+GLIBC_2.29 pmap_getport F
+GLIBC_2.29 pmap_rmtcall F
+GLIBC_2.29 pmap_set F
+GLIBC_2.29 pmap_unset F
+GLIBC_2.29 poll F
+GLIBC_2.29 popen F
+GLIBC_2.29 posix_fadvise F
+GLIBC_2.29 posix_fadvise64 F
+GLIBC_2.29 posix_fallocate F
+GLIBC_2.29 posix_fallocate64 F
+GLIBC_2.29 posix_madvise F
+GLIBC_2.29 posix_memalign F
+GLIBC_2.29 posix_openpt F
+GLIBC_2.29 posix_spawn F
+GLIBC_2.29 posix_spawn_file_actions_addchdir_np F
+GLIBC_2.29 posix_spawn_file_actions_addclose F
+GLIBC_2.29 posix_spawn_file_actions_adddup2 F
+GLIBC_2.29 posix_spawn_file_actions_addfchdir_np F
+GLIBC_2.29 posix_spawn_file_actions_addopen F
+GLIBC_2.29 posix_spawn_file_actions_destroy F
+GLIBC_2.29 posix_spawn_file_actions_init F
+GLIBC_2.29 posix_spawnattr_destroy F
+GLIBC_2.29 posix_spawnattr_getflags F
+GLIBC_2.29 posix_spawnattr_getpgroup F
+GLIBC_2.29 posix_spawnattr_getschedparam F
+GLIBC_2.29 posix_spawnattr_getschedpolicy F
+GLIBC_2.29 posix_spawnattr_getsigdefault F
+GLIBC_2.29 posix_spawnattr_getsigmask F
+GLIBC_2.29 posix_spawnattr_init F
+GLIBC_2.29 posix_spawnattr_setflags F
+GLIBC_2.29 posix_spawnattr_setpgroup F
+GLIBC_2.29 posix_spawnattr_setschedparam F
+GLIBC_2.29 posix_spawnattr_setschedpolicy F
+GLIBC_2.29 posix_spawnattr_setsigdefault F
+GLIBC_2.29 posix_spawnattr_setsigmask F
+GLIBC_2.29 posix_spawnp F
+GLIBC_2.29 ppoll F
+GLIBC_2.29 prctl F
+GLIBC_2.29 pread F
+GLIBC_2.29 pread64 F
+GLIBC_2.29 preadv F
+GLIBC_2.29 preadv2 F
+GLIBC_2.29 preadv64 F
+GLIBC_2.29 preadv64v2 F
+GLIBC_2.29 printf F
+GLIBC_2.29 printf_size F
+GLIBC_2.29 printf_size_info F
+GLIBC_2.29 prlimit F
+GLIBC_2.29 prlimit64 F
+GLIBC_2.29 process_vm_readv F
+GLIBC_2.29 process_vm_writev F
+GLIBC_2.29 profil F
+GLIBC_2.29 program_invocation_name D 0x4
+GLIBC_2.29 program_invocation_short_name D 0x4
+GLIBC_2.29 pselect F
+GLIBC_2.29 psiginfo F
+GLIBC_2.29 psignal F
+GLIBC_2.29 pthread_attr_destroy F
+GLIBC_2.29 pthread_attr_getdetachstate F
+GLIBC_2.29 pthread_attr_getinheritsched F
+GLIBC_2.29 pthread_attr_getschedparam F
+GLIBC_2.29 pthread_attr_getschedpolicy F
+GLIBC_2.29 pthread_attr_getscope F
+GLIBC_2.29 pthread_attr_init F
+GLIBC_2.29 pthread_attr_setdetachstate F
+GLIBC_2.29 pthread_attr_setinheritsched F
+GLIBC_2.29 pthread_attr_setschedparam F
+GLIBC_2.29 pthread_attr_setschedpolicy F
+GLIBC_2.29 pthread_attr_setscope F
+GLIBC_2.29 pthread_cond_broadcast F
+GLIBC_2.29 pthread_cond_destroy F
+GLIBC_2.29 pthread_cond_init F
+GLIBC_2.29 pthread_cond_signal F
+GLIBC_2.29 pthread_cond_timedwait F
+GLIBC_2.29 pthread_cond_wait F
+GLIBC_2.29 pthread_condattr_destroy F
+GLIBC_2.29 pthread_condattr_init F
+GLIBC_2.29 pthread_equal F
+GLIBC_2.29 pthread_exit F
+GLIBC_2.29 pthread_getschedparam F
+GLIBC_2.29 pthread_mutex_destroy F
+GLIBC_2.29 pthread_mutex_init F
+GLIBC_2.29 pthread_mutex_lock F
+GLIBC_2.29 pthread_mutex_unlock F
+GLIBC_2.29 pthread_self F
+GLIBC_2.29 pthread_setcancelstate F
+GLIBC_2.29 pthread_setcanceltype F
+GLIBC_2.29 pthread_setschedparam F
+GLIBC_2.29 ptrace F
+GLIBC_2.29 ptsname F
+GLIBC_2.29 ptsname_r F
+GLIBC_2.29 putc F
+GLIBC_2.29 putc_unlocked F
+GLIBC_2.29 putchar F
+GLIBC_2.29 putchar_unlocked F
+GLIBC_2.29 putenv F
+GLIBC_2.29 putgrent F
+GLIBC_2.29 putmsg F
+GLIBC_2.29 putpmsg F
+GLIBC_2.29 putpwent F
+GLIBC_2.29 puts F
+GLIBC_2.29 putsgent F
+GLIBC_2.29 putspent F
+GLIBC_2.29 pututline F
+GLIBC_2.29 pututxline F
+GLIBC_2.29 putw F
+GLIBC_2.29 putwc F
+GLIBC_2.29 putwc_unlocked F
+GLIBC_2.29 putwchar F
+GLIBC_2.29 putwchar_unlocked F
+GLIBC_2.29 pvalloc F
+GLIBC_2.29 pwrite F
+GLIBC_2.29 pwrite64 F
+GLIBC_2.29 pwritev F
+GLIBC_2.29 pwritev2 F
+GLIBC_2.29 pwritev64 F
+GLIBC_2.29 pwritev64v2 F
+GLIBC_2.29 qecvt F
+GLIBC_2.29 qecvt_r F
+GLIBC_2.29 qfcvt F
+GLIBC_2.29 qfcvt_r F
+GLIBC_2.29 qgcvt F
+GLIBC_2.29 qsort F
+GLIBC_2.29 qsort_r F
+GLIBC_2.29 quick_exit F
+GLIBC_2.29 quotactl F
+GLIBC_2.29 raise F
+GLIBC_2.29 rand F
+GLIBC_2.29 rand_r F
+GLIBC_2.29 random F
+GLIBC_2.29 random_r F
+GLIBC_2.29 rawmemchr F
+GLIBC_2.29 rcmd F
+GLIBC_2.29 rcmd_af F
+GLIBC_2.29 re_comp F
+GLIBC_2.29 re_compile_fastmap F
+GLIBC_2.29 re_compile_pattern F
+GLIBC_2.29 re_exec F
+GLIBC_2.29 re_match F
+GLIBC_2.29 re_match_2 F
+GLIBC_2.29 re_search F
+GLIBC_2.29 re_search_2 F
+GLIBC_2.29 re_set_registers F
+GLIBC_2.29 re_set_syntax F
+GLIBC_2.29 re_syntax_options D 0x4
+GLIBC_2.29 read F
+GLIBC_2.29 readahead F
+GLIBC_2.29 readdir F
+GLIBC_2.29 readdir64 F
+GLIBC_2.29 readdir64_r F
+GLIBC_2.29 readdir_r F
+GLIBC_2.29 readlink F
+GLIBC_2.29 readlinkat F
+GLIBC_2.29 readv F
+GLIBC_2.29 realloc F
+GLIBC_2.29 reallocarray F
+GLIBC_2.29 realpath F
+GLIBC_2.29 reboot F
+GLIBC_2.29 recv F
+GLIBC_2.29 recvfrom F
+GLIBC_2.29 recvmmsg F
+GLIBC_2.29 recvmsg F
+GLIBC_2.29 regcomp F
+GLIBC_2.29 regerror F
+GLIBC_2.29 regexec F
+GLIBC_2.29 regfree F
+GLIBC_2.29 register_printf_function F
+GLIBC_2.29 register_printf_modifier F
+GLIBC_2.29 register_printf_specifier F
+GLIBC_2.29 register_printf_type F
+GLIBC_2.29 registerrpc F
+GLIBC_2.29 remap_file_pages F
+GLIBC_2.29 remove F
+GLIBC_2.29 removexattr F
+GLIBC_2.29 remque F
+GLIBC_2.29 rename F
+GLIBC_2.29 renameat F
+GLIBC_2.29 renameat2 F
+GLIBC_2.29 revoke F
+GLIBC_2.29 rewind F
+GLIBC_2.29 rewinddir F
+GLIBC_2.29 rexec F
+GLIBC_2.29 rexec_af F
+GLIBC_2.29 rexecoptions D 0x4
+GLIBC_2.29 rindex F
+GLIBC_2.29 rmdir F
+GLIBC_2.29 rpc_createerr D 0x10
+GLIBC_2.29 rpmatch F
+GLIBC_2.29 rresvport F
+GLIBC_2.29 rresvport_af F
+GLIBC_2.29 rtime F
+GLIBC_2.29 ruserok F
+GLIBC_2.29 ruserok_af F
+GLIBC_2.29 ruserpass F
+GLIBC_2.29 sbrk F
+GLIBC_2.29 scalbn F
+GLIBC_2.29 scalbnf F
+GLIBC_2.29 scalbnl F
+GLIBC_2.29 scandir F
+GLIBC_2.29 scandir64 F
+GLIBC_2.29 scandirat F
+GLIBC_2.29 scandirat64 F
+GLIBC_2.29 scanf F
+GLIBC_2.29 sched_get_priority_max F
+GLIBC_2.29 sched_get_priority_min F
+GLIBC_2.29 sched_getaffinity F
+GLIBC_2.29 sched_getcpu F
+GLIBC_2.29 sched_getparam F
+GLIBC_2.29 sched_getscheduler F
+GLIBC_2.29 sched_rr_get_interval F
+GLIBC_2.29 sched_setaffinity F
+GLIBC_2.29 sched_setparam F
+GLIBC_2.29 sched_setscheduler F
+GLIBC_2.29 sched_yield F
+GLIBC_2.29 secure_getenv F
+GLIBC_2.29 seed48 F
+GLIBC_2.29 seed48_r F
+GLIBC_2.29 seekdir F
+GLIBC_2.29 select F
+GLIBC_2.29 semctl F
+GLIBC_2.29 semget F
+GLIBC_2.29 semop F
+GLIBC_2.29 semtimedop F
+GLIBC_2.29 send F
+GLIBC_2.29 sendfile F
+GLIBC_2.29 sendfile64 F
+GLIBC_2.29 sendmmsg F
+GLIBC_2.29 sendmsg F
+GLIBC_2.29 sendto F
+GLIBC_2.29 setaliasent F
+GLIBC_2.29 setbuf F
+GLIBC_2.29 setbuffer F
+GLIBC_2.29 setcontext F
+GLIBC_2.29 setdomainname F
+GLIBC_2.29 setegid F
+GLIBC_2.29 setenv F
+GLIBC_2.29 seteuid F
+GLIBC_2.29 setfsent F
+GLIBC_2.29 setfsgid F
+GLIBC_2.29 setfsuid F
+GLIBC_2.29 setgid F
+GLIBC_2.29 setgrent F
+GLIBC_2.29 setgroups F
+GLIBC_2.29 sethostent F
+GLIBC_2.29 sethostid F
+GLIBC_2.29 sethostname F
+GLIBC_2.29 setipv4sourcefilter F
+GLIBC_2.29 setitimer F
+GLIBC_2.29 setjmp F
+GLIBC_2.29 setlinebuf F
+GLIBC_2.29 setlocale F
+GLIBC_2.29 setlogin F
+GLIBC_2.29 setlogmask F
+GLIBC_2.29 setmntent F
+GLIBC_2.29 setnetent F
+GLIBC_2.29 setnetgrent F
+GLIBC_2.29 setns F
+GLIBC_2.29 setpgid F
+GLIBC_2.29 setpgrp F
+GLIBC_2.29 setpriority F
+GLIBC_2.29 setprotoent F
+GLIBC_2.29 setpwent F
+GLIBC_2.29 setregid F
+GLIBC_2.29 setresgid F
+GLIBC_2.29 setresuid F
+GLIBC_2.29 setreuid F
+GLIBC_2.29 setrlimit F
+GLIBC_2.29 setrlimit64 F
+GLIBC_2.29 setrpcent F
+GLIBC_2.29 setservent F
+GLIBC_2.29 setsgent F
+GLIBC_2.29 setsid F
+GLIBC_2.29 setsockopt F
+GLIBC_2.29 setsourcefilter F
+GLIBC_2.29 setspent F
+GLIBC_2.29 setstate F
+GLIBC_2.29 setstate_r F
+GLIBC_2.29 settimeofday F
+GLIBC_2.29 setttyent F
+GLIBC_2.29 setuid F
+GLIBC_2.29 setusershell F
+GLIBC_2.29 setutent F
+GLIBC_2.29 setutxent F
+GLIBC_2.29 setvbuf F
+GLIBC_2.29 setxattr F
+GLIBC_2.29 sgetsgent F
+GLIBC_2.29 sgetsgent_r F
+GLIBC_2.29 sgetspent F
+GLIBC_2.29 sgetspent_r F
+GLIBC_2.29 shmat F
+GLIBC_2.29 shmctl F
+GLIBC_2.29 shmdt F
+GLIBC_2.29 shmget F
+GLIBC_2.29 shutdown F
+GLIBC_2.29 sigaction F
+GLIBC_2.29 sigaddset F
+GLIBC_2.29 sigaltstack F
+GLIBC_2.29 sigandset F
+GLIBC_2.29 sigblock F
+GLIBC_2.29 sigdelset F
+GLIBC_2.29 sigemptyset F
+GLIBC_2.29 sigfillset F
+GLIBC_2.29 siggetmask F
+GLIBC_2.29 sighold F
+GLIBC_2.29 sigignore F
+GLIBC_2.29 siginterrupt F
+GLIBC_2.29 sigisemptyset F
+GLIBC_2.29 sigismember F
+GLIBC_2.29 siglongjmp F
+GLIBC_2.29 signal F
+GLIBC_2.29 signalfd F
+GLIBC_2.29 sigorset F
+GLIBC_2.29 sigpause F
+GLIBC_2.29 sigpending F
+GLIBC_2.29 sigprocmask F
+GLIBC_2.29 sigqueue F
+GLIBC_2.29 sigrelse F
+GLIBC_2.29 sigreturn F
+GLIBC_2.29 sigset F
+GLIBC_2.29 sigsetmask F
+GLIBC_2.29 sigstack F
+GLIBC_2.29 sigsuspend F
+GLIBC_2.29 sigtimedwait F
+GLIBC_2.29 sigwait F
+GLIBC_2.29 sigwaitinfo F
+GLIBC_2.29 sleep F
+GLIBC_2.29 snprintf F
+GLIBC_2.29 sockatmark F
+GLIBC_2.29 socket F
+GLIBC_2.29 socketpair F
+GLIBC_2.29 splice F
+GLIBC_2.29 sprintf F
+GLIBC_2.29 sprofil F
+GLIBC_2.29 srand F
+GLIBC_2.29 srand48 F
+GLIBC_2.29 srand48_r F
+GLIBC_2.29 srandom F
+GLIBC_2.29 srandom_r F
+GLIBC_2.29 sscanf F
+GLIBC_2.29 ssignal F
+GLIBC_2.29 sstk F
+GLIBC_2.29 statfs F
+GLIBC_2.29 statfs64 F
+GLIBC_2.29 statvfs F
+GLIBC_2.29 statvfs64 F
+GLIBC_2.29 statx F
+GLIBC_2.29 stderr D 0x4
+GLIBC_2.29 stdin D 0x4
+GLIBC_2.29 stdout D 0x4
+GLIBC_2.29 stime F
+GLIBC_2.29 stpcpy F
+GLIBC_2.29 stpncpy F
+GLIBC_2.29 strcasecmp F
+GLIBC_2.29 strcasecmp_l F
+GLIBC_2.29 strcasestr F
+GLIBC_2.29 strcat F
+GLIBC_2.29 strchr F
+GLIBC_2.29 strchrnul F
+GLIBC_2.29 strcmp F
+GLIBC_2.29 strcoll F
+GLIBC_2.29 strcoll_l F
+GLIBC_2.29 strcpy F
+GLIBC_2.29 strcspn F
+GLIBC_2.29 strdup F
+GLIBC_2.29 strerror F
+GLIBC_2.29 strerror_l F
+GLIBC_2.29 strerror_r F
+GLIBC_2.29 strfmon F
+GLIBC_2.29 strfmon_l F
+GLIBC_2.29 strfromd F
+GLIBC_2.29 strfromf F
+GLIBC_2.29 strfromf128 F
+GLIBC_2.29 strfromf32 F
+GLIBC_2.29 strfromf32x F
+GLIBC_2.29 strfromf64 F
+GLIBC_2.29 strfromf64x F
+GLIBC_2.29 strfroml F
+GLIBC_2.29 strfry F
+GLIBC_2.29 strftime F
+GLIBC_2.29 strftime_l F
+GLIBC_2.29 strlen F
+GLIBC_2.29 strncasecmp F
+GLIBC_2.29 strncasecmp_l F
+GLIBC_2.29 strncat F
+GLIBC_2.29 strncmp F
+GLIBC_2.29 strncpy F
+GLIBC_2.29 strndup F
+GLIBC_2.29 strnlen F
+GLIBC_2.29 strpbrk F
+GLIBC_2.29 strptime F
+GLIBC_2.29 strptime_l F
+GLIBC_2.29 strrchr F
+GLIBC_2.29 strsep F
+GLIBC_2.29 strsignal F
+GLIBC_2.29 strspn F
+GLIBC_2.29 strstr F
+GLIBC_2.29 strtod F
+GLIBC_2.29 strtod_l F
+GLIBC_2.29 strtof F
+GLIBC_2.29 strtof128 F
+GLIBC_2.29 strtof128_l F
+GLIBC_2.29 strtof32 F
+GLIBC_2.29 strtof32_l F
+GLIBC_2.29 strtof32x F
+GLIBC_2.29 strtof32x_l F
+GLIBC_2.29 strtof64 F
+GLIBC_2.29 strtof64_l F
+GLIBC_2.29 strtof64x F
+GLIBC_2.29 strtof64x_l F
+GLIBC_2.29 strtof_l F
+GLIBC_2.29 strtoimax F
+GLIBC_2.29 strtok F
+GLIBC_2.29 strtok_r F
+GLIBC_2.29 strtol F
+GLIBC_2.29 strtol_l F
+GLIBC_2.29 strtold F
+GLIBC_2.29 strtold_l F
+GLIBC_2.29 strtoll F
+GLIBC_2.29 strtoll_l F
+GLIBC_2.29 strtoq F
+GLIBC_2.29 strtoul F
+GLIBC_2.29 strtoul_l F
+GLIBC_2.29 strtoull F
+GLIBC_2.29 strtoull_l F
+GLIBC_2.29 strtoumax F
+GLIBC_2.29 strtouq F
+GLIBC_2.29 strverscmp F
+GLIBC_2.29 strxfrm F
+GLIBC_2.29 strxfrm_l F
+GLIBC_2.29 stty F
+GLIBC_2.29 svc_exit F
+GLIBC_2.29 svc_fdset D 0x80
+GLIBC_2.29 svc_getreq F
+GLIBC_2.29 svc_getreq_common F
+GLIBC_2.29 svc_getreq_poll F
+GLIBC_2.29 svc_getreqset F
+GLIBC_2.29 svc_max_pollfd D 0x4
+GLIBC_2.29 svc_pollfd D 0x4
+GLIBC_2.29 svc_register F
+GLIBC_2.29 svc_run F
+GLIBC_2.29 svc_sendreply F
+GLIBC_2.29 svc_unregister F
+GLIBC_2.29 svcauthdes_stats D 0xc
+GLIBC_2.29 svcerr_auth F
+GLIBC_2.29 svcerr_decode F
+GLIBC_2.29 svcerr_noproc F
+GLIBC_2.29 svcerr_noprog F
+GLIBC_2.29 svcerr_progvers F
+GLIBC_2.29 svcerr_systemerr F
+GLIBC_2.29 svcerr_weakauth F
+GLIBC_2.29 svcfd_create F
+GLIBC_2.29 svcraw_create F
+GLIBC_2.29 svctcp_create F
+GLIBC_2.29 svcudp_bufcreate F
+GLIBC_2.29 svcudp_create F
+GLIBC_2.29 svcudp_enablecache F
+GLIBC_2.29 svcunix_create F
+GLIBC_2.29 svcunixfd_create F
+GLIBC_2.29 swab F
+GLIBC_2.29 swapcontext F
+GLIBC_2.29 swapoff F
+GLIBC_2.29 swapon F
+GLIBC_2.29 swprintf F
+GLIBC_2.29 swscanf F
+GLIBC_2.29 symlink F
+GLIBC_2.29 symlinkat F
+GLIBC_2.29 sync F
+GLIBC_2.29 sync_file_range F
+GLIBC_2.29 syncfs F
+GLIBC_2.29 sys_errlist D 0x21c
+GLIBC_2.29 sys_nerr D 0x4
+GLIBC_2.29 sys_sigabbrev D 0x104
+GLIBC_2.29 sys_siglist D 0x104
+GLIBC_2.29 syscall F
+GLIBC_2.29 sysconf F
+GLIBC_2.29 sysctl F
+GLIBC_2.29 sysinfo F
+GLIBC_2.29 syslog F
+GLIBC_2.29 system F
+GLIBC_2.29 sysv_signal F
+GLIBC_2.29 tcdrain F
+GLIBC_2.29 tcflow F
+GLIBC_2.29 tcflush F
+GLIBC_2.29 tcgetattr F
+GLIBC_2.29 tcgetpgrp F
+GLIBC_2.29 tcgetsid F
+GLIBC_2.29 tcsendbreak F
+GLIBC_2.29 tcsetattr F
+GLIBC_2.29 tcsetpgrp F
+GLIBC_2.29 tdelete F
+GLIBC_2.29 tdestroy F
+GLIBC_2.29 tee F
+GLIBC_2.29 telldir F
+GLIBC_2.29 tempnam F
+GLIBC_2.29 textdomain F
+GLIBC_2.29 tfind F
+GLIBC_2.29 thrd_current F
+GLIBC_2.29 thrd_equal F
+GLIBC_2.29 thrd_sleep F
+GLIBC_2.29 thrd_yield F
+GLIBC_2.29 time F
+GLIBC_2.29 timegm F
+GLIBC_2.29 timelocal F
+GLIBC_2.29 timerfd_create F
+GLIBC_2.29 timerfd_gettime F
+GLIBC_2.29 timerfd_settime F
+GLIBC_2.29 times F
+GLIBC_2.29 timespec_get F
+GLIBC_2.29 timezone D 0x4
+GLIBC_2.29 tmpfile F
+GLIBC_2.29 tmpfile64 F
+GLIBC_2.29 tmpnam F
+GLIBC_2.29 tmpnam_r F
+GLIBC_2.29 toascii F
+GLIBC_2.29 tolower F
+GLIBC_2.29 tolower_l F
+GLIBC_2.29 toupper F
+GLIBC_2.29 toupper_l F
+GLIBC_2.29 towctrans F
+GLIBC_2.29 towctrans_l F
+GLIBC_2.29 towlower F
+GLIBC_2.29 towlower_l F
+GLIBC_2.29 towupper F
+GLIBC_2.29 towupper_l F
+GLIBC_2.29 tr_break F
+GLIBC_2.29 truncate F
+GLIBC_2.29 truncate64 F
+GLIBC_2.29 tsearch F
+GLIBC_2.29 ttyname F
+GLIBC_2.29 ttyname_r F
+GLIBC_2.29 ttyslot F
+GLIBC_2.29 twalk F
+GLIBC_2.29 tzname D 0x8
+GLIBC_2.29 tzset F
+GLIBC_2.29 ualarm F
+GLIBC_2.29 ulckpwdf F
+GLIBC_2.29 ulimit F
+GLIBC_2.29 umask F
+GLIBC_2.29 umount F
+GLIBC_2.29 umount2 F
+GLIBC_2.29 uname F
+GLIBC_2.29 ungetc F
+GLIBC_2.29 ungetwc F
+GLIBC_2.29 unlink F
+GLIBC_2.29 unlinkat F
+GLIBC_2.29 unlockpt F
+GLIBC_2.29 unsetenv F
+GLIBC_2.29 unshare F
+GLIBC_2.29 updwtmp F
+GLIBC_2.29 updwtmpx F
+GLIBC_2.29 uselocale F
+GLIBC_2.29 user2netname F
+GLIBC_2.29 usleep F
+GLIBC_2.29 utime F
+GLIBC_2.29 utimensat F
+GLIBC_2.29 utimes F
+GLIBC_2.29 utmpname F
+GLIBC_2.29 utmpxname F
+GLIBC_2.29 valloc F
+GLIBC_2.29 vasprintf F
+GLIBC_2.29 vdprintf F
+GLIBC_2.29 verr F
+GLIBC_2.29 verrx F
+GLIBC_2.29 versionsort F
+GLIBC_2.29 versionsort64 F
+GLIBC_2.29 vfork F
+GLIBC_2.29 vfprintf F
+GLIBC_2.29 vfscanf F
+GLIBC_2.29 vfwprintf F
+GLIBC_2.29 vfwscanf F
+GLIBC_2.29 vhangup F
+GLIBC_2.29 vlimit F
+GLIBC_2.29 vmsplice F
+GLIBC_2.29 vprintf F
+GLIBC_2.29 vscanf F
+GLIBC_2.29 vsnprintf F
+GLIBC_2.29 vsprintf F
+GLIBC_2.29 vsscanf F
+GLIBC_2.29 vswprintf F
+GLIBC_2.29 vswscanf F
+GLIBC_2.29 vsyslog F
+GLIBC_2.29 vtimes F
+GLIBC_2.29 vwarn F
+GLIBC_2.29 vwarnx F
+GLIBC_2.29 vwprintf F
+GLIBC_2.29 vwscanf F
+GLIBC_2.29 wait F
+GLIBC_2.29 wait3 F
+GLIBC_2.29 wait4 F
+GLIBC_2.29 waitid F
+GLIBC_2.29 waitpid F
+GLIBC_2.29 warn F
+GLIBC_2.29 warnx F
+GLIBC_2.29 wcpcpy F
+GLIBC_2.29 wcpncpy F
+GLIBC_2.29 wcrtomb F
+GLIBC_2.29 wcscasecmp F
+GLIBC_2.29 wcscasecmp_l F
+GLIBC_2.29 wcscat F
+GLIBC_2.29 wcschr F
+GLIBC_2.29 wcschrnul F
+GLIBC_2.29 wcscmp F
+GLIBC_2.29 wcscoll F
+GLIBC_2.29 wcscoll_l F
+GLIBC_2.29 wcscpy F
+GLIBC_2.29 wcscspn F
+GLIBC_2.29 wcsdup F
+GLIBC_2.29 wcsftime F
+GLIBC_2.29 wcsftime_l F
+GLIBC_2.29 wcslen F
+GLIBC_2.29 wcsncasecmp F
+GLIBC_2.29 wcsncasecmp_l F
+GLIBC_2.29 wcsncat F
+GLIBC_2.29 wcsncmp F
+GLIBC_2.29 wcsncpy F
+GLIBC_2.29 wcsnlen F
+GLIBC_2.29 wcsnrtombs F
+GLIBC_2.29 wcspbrk F
+GLIBC_2.29 wcsrchr F
+GLIBC_2.29 wcsrtombs F
+GLIBC_2.29 wcsspn F
+GLIBC_2.29 wcsstr F
+GLIBC_2.29 wcstod F
+GLIBC_2.29 wcstod_l F
+GLIBC_2.29 wcstof F
+GLIBC_2.29 wcstof128 F
+GLIBC_2.29 wcstof128_l F
+GLIBC_2.29 wcstof32 F
+GLIBC_2.29 wcstof32_l F
+GLIBC_2.29 wcstof32x F
+GLIBC_2.29 wcstof32x_l F
+GLIBC_2.29 wcstof64 F
+GLIBC_2.29 wcstof64_l F
+GLIBC_2.29 wcstof64x F
+GLIBC_2.29 wcstof64x_l F
+GLIBC_2.29 wcstof_l F
+GLIBC_2.29 wcstoimax F
+GLIBC_2.29 wcstok F
+GLIBC_2.29 wcstol F
+GLIBC_2.29 wcstol_l F
+GLIBC_2.29 wcstold F
+GLIBC_2.29 wcstold_l F
+GLIBC_2.29 wcstoll F
+GLIBC_2.29 wcstoll_l F
+GLIBC_2.29 wcstombs F
+GLIBC_2.29 wcstoq F
+GLIBC_2.29 wcstoul F
+GLIBC_2.29 wcstoul_l F
+GLIBC_2.29 wcstoull F
+GLIBC_2.29 wcstoull_l F
+GLIBC_2.29 wcstoumax F
+GLIBC_2.29 wcstouq F
+GLIBC_2.29 wcswcs F
+GLIBC_2.29 wcswidth F
+GLIBC_2.29 wcsxfrm F
+GLIBC_2.29 wcsxfrm_l F
+GLIBC_2.29 wctob F
+GLIBC_2.29 wctomb F
+GLIBC_2.29 wctrans F
+GLIBC_2.29 wctrans_l F
+GLIBC_2.29 wctype F
+GLIBC_2.29 wctype_l F
+GLIBC_2.29 wcwidth F
+GLIBC_2.29 wmemchr F
+GLIBC_2.29 wmemcmp F
+GLIBC_2.29 wmemcpy F
+GLIBC_2.29 wmemmove F
+GLIBC_2.29 wmempcpy F
+GLIBC_2.29 wmemset F
+GLIBC_2.29 wordexp F
+GLIBC_2.29 wordfree F
+GLIBC_2.29 wprintf F
+GLIBC_2.29 write F
+GLIBC_2.29 writev F
+GLIBC_2.29 wscanf F
+GLIBC_2.29 xdecrypt F
+GLIBC_2.29 xdr_accepted_reply F
+GLIBC_2.29 xdr_array F
+GLIBC_2.29 xdr_authdes_cred F
+GLIBC_2.29 xdr_authdes_verf F
+GLIBC_2.29 xdr_authunix_parms F
+GLIBC_2.29 xdr_bool F
+GLIBC_2.29 xdr_bytes F
+GLIBC_2.29 xdr_callhdr F
+GLIBC_2.29 xdr_callmsg F
+GLIBC_2.29 xdr_char F
+GLIBC_2.29 xdr_cryptkeyarg F
+GLIBC_2.29 xdr_cryptkeyarg2 F
+GLIBC_2.29 xdr_cryptkeyres F
+GLIBC_2.29 xdr_des_block F
+GLIBC_2.29 xdr_double F
+GLIBC_2.29 xdr_enum F
+GLIBC_2.29 xdr_float F
+GLIBC_2.29 xdr_free F
+GLIBC_2.29 xdr_getcredres F
+GLIBC_2.29 xdr_hyper F
+GLIBC_2.29 xdr_int F
+GLIBC_2.29 xdr_int16_t F
+GLIBC_2.29 xdr_int32_t F
+GLIBC_2.29 xdr_int64_t F
+GLIBC_2.29 xdr_int8_t F
+GLIBC_2.29 xdr_key_netstarg F
+GLIBC_2.29 xdr_key_netstres F
+GLIBC_2.29 xdr_keybuf F
+GLIBC_2.29 xdr_keystatus F
+GLIBC_2.29 xdr_long F
+GLIBC_2.29 xdr_longlong_t F
+GLIBC_2.29 xdr_netnamestr F
+GLIBC_2.29 xdr_netobj F
+GLIBC_2.29 xdr_opaque F
+GLIBC_2.29 xdr_opaque_auth F
+GLIBC_2.29 xdr_pmap F
+GLIBC_2.29 xdr_pmaplist F
+GLIBC_2.29 xdr_pointer F
+GLIBC_2.29 xdr_quad_t F
+GLIBC_2.29 xdr_reference F
+GLIBC_2.29 xdr_rejected_reply F
+GLIBC_2.29 xdr_replymsg F
+GLIBC_2.29 xdr_rmtcall_args F
+GLIBC_2.29 xdr_rmtcallres F
+GLIBC_2.29 xdr_short F
+GLIBC_2.29 xdr_sizeof F
+GLIBC_2.29 xdr_string F
+GLIBC_2.29 xdr_u_char F
+GLIBC_2.29 xdr_u_hyper F
+GLIBC_2.29 xdr_u_int F
+GLIBC_2.29 xdr_u_long F
+GLIBC_2.29 xdr_u_longlong_t F
+GLIBC_2.29 xdr_u_quad_t F
+GLIBC_2.29 xdr_u_short F
+GLIBC_2.29 xdr_uint16_t F
+GLIBC_2.29 xdr_uint32_t F
+GLIBC_2.29 xdr_uint64_t F
+GLIBC_2.29 xdr_uint8_t F
+GLIBC_2.29 xdr_union F
+GLIBC_2.29 xdr_unixcred F
+GLIBC_2.29 xdr_vector F
+GLIBC_2.29 xdr_void F
+GLIBC_2.29 xdr_wrapstring F
+GLIBC_2.29 xdrmem_create F
+GLIBC_2.29 xdrrec_create F
+GLIBC_2.29 xdrrec_endofrecord F
+GLIBC_2.29 xdrrec_eof F
+GLIBC_2.29 xdrrec_skiprecord F
+GLIBC_2.29 xdrstdio_create F
+GLIBC_2.29 xencrypt F
+GLIBC_2.29 xprt_register F
+GLIBC_2.29 xprt_unregister F
diff --git a/sysdeps/unix/sysv/linux/riscv/rv32/libcrypt.abilist b/sysdeps/unix/sysv/linux/riscv/rv32/libcrypt.abilist
new file mode 100644
index 0000000000..da3abbf8fb
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/rv32/libcrypt.abilist
@@ -0,0 +1,2 @@
+GLIBC_2.29 crypt F
+GLIBC_2.29 crypt_r F
diff --git a/sysdeps/unix/sysv/linux/riscv/rv32/libdl.abilist b/sysdeps/unix/sysv/linux/riscv/rv32/libdl.abilist
new file mode 100644
index 0000000000..8fcb609ddc
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/rv32/libdl.abilist
@@ -0,0 +1,9 @@
+GLIBC_2.29 dladdr F
+GLIBC_2.29 dladdr1 F
+GLIBC_2.29 dlclose F
+GLIBC_2.29 dlerror F
+GLIBC_2.29 dlinfo F
+GLIBC_2.29 dlmopen F
+GLIBC_2.29 dlopen F
+GLIBC_2.29 dlsym F
+GLIBC_2.29 dlvsym F
diff --git a/sysdeps/unix/sysv/linux/riscv/rv32/libm.abilist b/sysdeps/unix/sysv/linux/riscv/rv32/libm.abilist
new file mode 100644
index 0000000000..f7e19f44ab
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/rv32/libm.abilist
@@ -0,0 +1,1021 @@
+GLIBC_2.29 __acos_finite F
+GLIBC_2.29 __acosf_finite F
+GLIBC_2.29 __acosh_finite F
+GLIBC_2.29 __acoshf_finite F
+GLIBC_2.29 __acoshl_finite F
+GLIBC_2.29 __acosl_finite F
+GLIBC_2.29 __asin_finite F
+GLIBC_2.29 __asinf_finite F
+GLIBC_2.29 __asinl_finite F
+GLIBC_2.29 __atan2_finite F
+GLIBC_2.29 __atan2f_finite F
+GLIBC_2.29 __atan2l_finite F
+GLIBC_2.29 __atanh_finite F
+GLIBC_2.29 __atanhf_finite F
+GLIBC_2.29 __atanhl_finite F
+GLIBC_2.29 __clog10 F
+GLIBC_2.29 __clog10f F
+GLIBC_2.29 __clog10l F
+GLIBC_2.29 __cosh_finite F
+GLIBC_2.29 __coshf_finite F
+GLIBC_2.29 __coshl_finite F
+GLIBC_2.29 __exp10_finite F
+GLIBC_2.29 __exp10f_finite F
+GLIBC_2.29 __exp10l_finite F
+GLIBC_2.29 __exp2_finite F
+GLIBC_2.29 __exp2f_finite F
+GLIBC_2.29 __exp2l_finite F
+GLIBC_2.29 __exp_finite F
+GLIBC_2.29 __expf_finite F
+GLIBC_2.29 __expl_finite F
+GLIBC_2.29 __finite F
+GLIBC_2.29 __finitef F
+GLIBC_2.29 __finitel F
+GLIBC_2.29 __fmod_finite F
+GLIBC_2.29 __fmodf_finite F
+GLIBC_2.29 __fmodl_finite F
+GLIBC_2.29 __fpclassify F
+GLIBC_2.29 __fpclassifyf F
+GLIBC_2.29 __fpclassifyl F
+GLIBC_2.29 __gamma_r_finite F
+GLIBC_2.29 __gammaf_r_finite F
+GLIBC_2.29 __gammal_r_finite F
+GLIBC_2.29 __hypot_finite F
+GLIBC_2.29 __hypotf_finite F
+GLIBC_2.29 __hypotl_finite F
+GLIBC_2.29 __iseqsig F
+GLIBC_2.29 __iseqsigf F
+GLIBC_2.29 __iseqsigl F
+GLIBC_2.29 __issignaling F
+GLIBC_2.29 __issignalingf F
+GLIBC_2.29 __issignalingl F
+GLIBC_2.29 __j0_finite F
+GLIBC_2.29 __j0f_finite F
+GLIBC_2.29 __j0l_finite F
+GLIBC_2.29 __j1_finite F
+GLIBC_2.29 __j1f_finite F
+GLIBC_2.29 __j1l_finite F
+GLIBC_2.29 __jn_finite F
+GLIBC_2.29 __jnf_finite F
+GLIBC_2.29 __jnl_finite F
+GLIBC_2.29 __lgamma_r_finite F
+GLIBC_2.29 __lgammaf_r_finite F
+GLIBC_2.29 __lgammal_r_finite F
+GLIBC_2.29 __log10_finite F
+GLIBC_2.29 __log10f_finite F
+GLIBC_2.29 __log10l_finite F
+GLIBC_2.29 __log2_finite F
+GLIBC_2.29 __log2f_finite F
+GLIBC_2.29 __log2l_finite F
+GLIBC_2.29 __log_finite F
+GLIBC_2.29 __logf_finite F
+GLIBC_2.29 __logl_finite F
+GLIBC_2.29 __pow_finite F
+GLIBC_2.29 __powf_finite F
+GLIBC_2.29 __powl_finite F
+GLIBC_2.29 __remainder_finite F
+GLIBC_2.29 __remainderf_finite F
+GLIBC_2.29 __remainderl_finite F
+GLIBC_2.29 __scalb_finite F
+GLIBC_2.29 __scalbf_finite F
+GLIBC_2.29 __scalbl_finite F
+GLIBC_2.29 __signbit F
+GLIBC_2.29 __signbitf F
+GLIBC_2.29 __signbitl F
+GLIBC_2.29 __signgam D 0x4
+GLIBC_2.29 __sinh_finite F
+GLIBC_2.29 __sinhf_finite F
+GLIBC_2.29 __sinhl_finite F
+GLIBC_2.29 __sqrt_finite F
+GLIBC_2.29 __sqrtf_finite F
+GLIBC_2.29 __sqrtl_finite F
+GLIBC_2.29 __y0_finite F
+GLIBC_2.29 __y0f_finite F
+GLIBC_2.29 __y0l_finite F
+GLIBC_2.29 __y1_finite F
+GLIBC_2.29 __y1f_finite F
+GLIBC_2.29 __y1l_finite F
+GLIBC_2.29 __yn_finite F
+GLIBC_2.29 __ynf_finite F
+GLIBC_2.29 __ynl_finite F
+GLIBC_2.29 acos F
+GLIBC_2.29 acosf F
+GLIBC_2.29 acosf128 F
+GLIBC_2.29 acosf32 F
+GLIBC_2.29 acosf32x F
+GLIBC_2.29 acosf64 F
+GLIBC_2.29 acosf64x F
+GLIBC_2.29 acosh F
+GLIBC_2.29 acoshf F
+GLIBC_2.29 acoshf128 F
+GLIBC_2.29 acoshf32 F
+GLIBC_2.29 acoshf32x F
+GLIBC_2.29 acoshf64 F
+GLIBC_2.29 acoshf64x F
+GLIBC_2.29 acoshl F
+GLIBC_2.29 acosl F
+GLIBC_2.29 asin F
+GLIBC_2.29 asinf F
+GLIBC_2.29 asinf128 F
+GLIBC_2.29 asinf32 F
+GLIBC_2.29 asinf32x F
+GLIBC_2.29 asinf64 F
+GLIBC_2.29 asinf64x F
+GLIBC_2.29 asinh F
+GLIBC_2.29 asinhf F
+GLIBC_2.29 asinhf128 F
+GLIBC_2.29 asinhf32 F
+GLIBC_2.29 asinhf32x F
+GLIBC_2.29 asinhf64 F
+GLIBC_2.29 asinhf64x F
+GLIBC_2.29 asinhl F
+GLIBC_2.29 asinl F
+GLIBC_2.29 atan F
+GLIBC_2.29 atan2 F
+GLIBC_2.29 atan2f F
+GLIBC_2.29 atan2f128 F
+GLIBC_2.29 atan2f32 F
+GLIBC_2.29 atan2f32x F
+GLIBC_2.29 atan2f64 F
+GLIBC_2.29 atan2f64x F
+GLIBC_2.29 atan2l F
+GLIBC_2.29 atanf F
+GLIBC_2.29 atanf128 F
+GLIBC_2.29 atanf32 F
+GLIBC_2.29 atanf32x F
+GLIBC_2.29 atanf64 F
+GLIBC_2.29 atanf64x F
+GLIBC_2.29 atanh F
+GLIBC_2.29 atanhf F
+GLIBC_2.29 atanhf128 F
+GLIBC_2.29 atanhf32 F
+GLIBC_2.29 atanhf32x F
+GLIBC_2.29 atanhf64 F
+GLIBC_2.29 atanhf64x F
+GLIBC_2.29 atanhl F
+GLIBC_2.29 atanl F
+GLIBC_2.29 cabs F
+GLIBC_2.29 cabsf F
+GLIBC_2.29 cabsf128 F
+GLIBC_2.29 cabsf32 F
+GLIBC_2.29 cabsf32x F
+GLIBC_2.29 cabsf64 F
+GLIBC_2.29 cabsf64x F
+GLIBC_2.29 cabsl F
+GLIBC_2.29 cacos F
+GLIBC_2.29 cacosf F
+GLIBC_2.29 cacosf128 F
+GLIBC_2.29 cacosf32 F
+GLIBC_2.29 cacosf32x F
+GLIBC_2.29 cacosf64 F
+GLIBC_2.29 cacosf64x F
+GLIBC_2.29 cacosh F
+GLIBC_2.29 cacoshf F
+GLIBC_2.29 cacoshf128 F
+GLIBC_2.29 cacoshf32 F
+GLIBC_2.29 cacoshf32x F
+GLIBC_2.29 cacoshf64 F
+GLIBC_2.29 cacoshf64x F
+GLIBC_2.29 cacoshl F
+GLIBC_2.29 cacosl F
+GLIBC_2.29 canonicalize F
+GLIBC_2.29 canonicalizef F
+GLIBC_2.29 canonicalizef128 F
+GLIBC_2.29 canonicalizef32 F
+GLIBC_2.29 canonicalizef32x F
+GLIBC_2.29 canonicalizef64 F
+GLIBC_2.29 canonicalizef64x F
+GLIBC_2.29 canonicalizel F
+GLIBC_2.29 carg F
+GLIBC_2.29 cargf F
+GLIBC_2.29 cargf128 F
+GLIBC_2.29 cargf32 F
+GLIBC_2.29 cargf32x F
+GLIBC_2.29 cargf64 F
+GLIBC_2.29 cargf64x F
+GLIBC_2.29 cargl F
+GLIBC_2.29 casin F
+GLIBC_2.29 casinf F
+GLIBC_2.29 casinf128 F
+GLIBC_2.29 casinf32 F
+GLIBC_2.29 casinf32x F
+GLIBC_2.29 casinf64 F
+GLIBC_2.29 casinf64x F
+GLIBC_2.29 casinh F
+GLIBC_2.29 casinhf F
+GLIBC_2.29 casinhf128 F
+GLIBC_2.29 casinhf32 F
+GLIBC_2.29 casinhf32x F
+GLIBC_2.29 casinhf64 F
+GLIBC_2.29 casinhf64x F
+GLIBC_2.29 casinhl F
+GLIBC_2.29 casinl F
+GLIBC_2.29 catan F
+GLIBC_2.29 catanf F
+GLIBC_2.29 catanf128 F
+GLIBC_2.29 catanf32 F
+GLIBC_2.29 catanf32x F
+GLIBC_2.29 catanf64 F
+GLIBC_2.29 catanf64x F
+GLIBC_2.29 catanh F
+GLIBC_2.29 catanhf F
+GLIBC_2.29 catanhf128 F
+GLIBC_2.29 catanhf32 F
+GLIBC_2.29 catanhf32x F
+GLIBC_2.29 catanhf64 F
+GLIBC_2.29 catanhf64x F
+GLIBC_2.29 catanhl F
+GLIBC_2.29 catanl F
+GLIBC_2.29 cbrt F
+GLIBC_2.29 cbrtf F
+GLIBC_2.29 cbrtf128 F
+GLIBC_2.29 cbrtf32 F
+GLIBC_2.29 cbrtf32x F
+GLIBC_2.29 cbrtf64 F
+GLIBC_2.29 cbrtf64x F
+GLIBC_2.29 cbrtl F
+GLIBC_2.29 ccos F
+GLIBC_2.29 ccosf F
+GLIBC_2.29 ccosf128 F
+GLIBC_2.29 ccosf32 F
+GLIBC_2.29 ccosf32x F
+GLIBC_2.29 ccosf64 F
+GLIBC_2.29 ccosf64x F
+GLIBC_2.29 ccosh F
+GLIBC_2.29 ccoshf F
+GLIBC_2.29 ccoshf128 F
+GLIBC_2.29 ccoshf32 F
+GLIBC_2.29 ccoshf32x F
+GLIBC_2.29 ccoshf64 F
+GLIBC_2.29 ccoshf64x F
+GLIBC_2.29 ccoshl F
+GLIBC_2.29 ccosl F
+GLIBC_2.29 ceil F
+GLIBC_2.29 ceilf F
+GLIBC_2.29 ceilf128 F
+GLIBC_2.29 ceilf32 F
+GLIBC_2.29 ceilf32x F
+GLIBC_2.29 ceilf64 F
+GLIBC_2.29 ceilf64x F
+GLIBC_2.29 ceill F
+GLIBC_2.29 cexp F
+GLIBC_2.29 cexpf F
+GLIBC_2.29 cexpf128 F
+GLIBC_2.29 cexpf32 F
+GLIBC_2.29 cexpf32x F
+GLIBC_2.29 cexpf64 F
+GLIBC_2.29 cexpf64x F
+GLIBC_2.29 cexpl F
+GLIBC_2.29 cimag F
+GLIBC_2.29 cimagf F
+GLIBC_2.29 cimagf128 F
+GLIBC_2.29 cimagf32 F
+GLIBC_2.29 cimagf32x F
+GLIBC_2.29 cimagf64 F
+GLIBC_2.29 cimagf64x F
+GLIBC_2.29 cimagl F
+GLIBC_2.29 clog F
+GLIBC_2.29 clog10 F
+GLIBC_2.29 clog10f F
+GLIBC_2.29 clog10f128 F
+GLIBC_2.29 clog10f32 F
+GLIBC_2.29 clog10f32x F
+GLIBC_2.29 clog10f64 F
+GLIBC_2.29 clog10f64x F
+GLIBC_2.29 clog10l F
+GLIBC_2.29 clogf F
+GLIBC_2.29 clogf128 F
+GLIBC_2.29 clogf32 F
+GLIBC_2.29 clogf32x F
+GLIBC_2.29 clogf64 F
+GLIBC_2.29 clogf64x F
+GLIBC_2.29 clogl F
+GLIBC_2.29 conj F
+GLIBC_2.29 conjf F
+GLIBC_2.29 conjf128 F
+GLIBC_2.29 conjf32 F
+GLIBC_2.29 conjf32x F
+GLIBC_2.29 conjf64 F
+GLIBC_2.29 conjf64x F
+GLIBC_2.29 conjl F
+GLIBC_2.29 copysign F
+GLIBC_2.29 copysignf F
+GLIBC_2.29 copysignf128 F
+GLIBC_2.29 copysignf32 F
+GLIBC_2.29 copysignf32x F
+GLIBC_2.29 copysignf64 F
+GLIBC_2.29 copysignf64x F
+GLIBC_2.29 copysignl F
+GLIBC_2.29 cos F
+GLIBC_2.29 cosf F
+GLIBC_2.29 cosf128 F
+GLIBC_2.29 cosf32 F
+GLIBC_2.29 cosf32x F
+GLIBC_2.29 cosf64 F
+GLIBC_2.29 cosf64x F
+GLIBC_2.29 cosh F
+GLIBC_2.29 coshf F
+GLIBC_2.29 coshf128 F
+GLIBC_2.29 coshf32 F
+GLIBC_2.29 coshf32x F
+GLIBC_2.29 coshf64 F
+GLIBC_2.29 coshf64x F
+GLIBC_2.29 coshl F
+GLIBC_2.29 cosl F
+GLIBC_2.29 cpow F
+GLIBC_2.29 cpowf F
+GLIBC_2.29 cpowf128 F
+GLIBC_2.29 cpowf32 F
+GLIBC_2.29 cpowf32x F
+GLIBC_2.29 cpowf64 F
+GLIBC_2.29 cpowf64x F
+GLIBC_2.29 cpowl F
+GLIBC_2.29 cproj F
+GLIBC_2.29 cprojf F
+GLIBC_2.29 cprojf128 F
+GLIBC_2.29 cprojf32 F
+GLIBC_2.29 cprojf32x F
+GLIBC_2.29 cprojf64 F
+GLIBC_2.29 cprojf64x F
+GLIBC_2.29 cprojl F
+GLIBC_2.29 creal F
+GLIBC_2.29 crealf F
+GLIBC_2.29 crealf128 F
+GLIBC_2.29 crealf32 F
+GLIBC_2.29 crealf32x F
+GLIBC_2.29 crealf64 F
+GLIBC_2.29 crealf64x F
+GLIBC_2.29 creall F
+GLIBC_2.29 csin F
+GLIBC_2.29 csinf F
+GLIBC_2.29 csinf128 F
+GLIBC_2.29 csinf32 F
+GLIBC_2.29 csinf32x F
+GLIBC_2.29 csinf64 F
+GLIBC_2.29 csinf64x F
+GLIBC_2.29 csinh F
+GLIBC_2.29 csinhf F
+GLIBC_2.29 csinhf128 F
+GLIBC_2.29 csinhf32 F
+GLIBC_2.29 csinhf32x F
+GLIBC_2.29 csinhf64 F
+GLIBC_2.29 csinhf64x F
+GLIBC_2.29 csinhl F
+GLIBC_2.29 csinl F
+GLIBC_2.29 csqrt F
+GLIBC_2.29 csqrtf F
+GLIBC_2.29 csqrtf128 F
+GLIBC_2.29 csqrtf32 F
+GLIBC_2.29 csqrtf32x F
+GLIBC_2.29 csqrtf64 F
+GLIBC_2.29 csqrtf64x F
+GLIBC_2.29 csqrtl F
+GLIBC_2.29 ctan F
+GLIBC_2.29 ctanf F
+GLIBC_2.29 ctanf128 F
+GLIBC_2.29 ctanf32 F
+GLIBC_2.29 ctanf32x F
+GLIBC_2.29 ctanf64 F
+GLIBC_2.29 ctanf64x F
+GLIBC_2.29 ctanh F
+GLIBC_2.29 ctanhf F
+GLIBC_2.29 ctanhf128 F
+GLIBC_2.29 ctanhf32 F
+GLIBC_2.29 ctanhf32x F
+GLIBC_2.29 ctanhf64 F
+GLIBC_2.29 ctanhf64x F
+GLIBC_2.29 ctanhl F
+GLIBC_2.29 ctanl F
+GLIBC_2.29 daddl F
+GLIBC_2.29 ddivl F
+GLIBC_2.29 dmull F
+GLIBC_2.29 drem F
+GLIBC_2.29 dremf F
+GLIBC_2.29 dreml F
+GLIBC_2.29 dsubl F
+GLIBC_2.29 erf F
+GLIBC_2.29 erfc F
+GLIBC_2.29 erfcf F
+GLIBC_2.29 erfcf128 F
+GLIBC_2.29 erfcf32 F
+GLIBC_2.29 erfcf32x F
+GLIBC_2.29 erfcf64 F
+GLIBC_2.29 erfcf64x F
+GLIBC_2.29 erfcl F
+GLIBC_2.29 erff F
+GLIBC_2.29 erff128 F
+GLIBC_2.29 erff32 F
+GLIBC_2.29 erff32x F
+GLIBC_2.29 erff64 F
+GLIBC_2.29 erff64x F
+GLIBC_2.29 erfl F
+GLIBC_2.29 exp F
+GLIBC_2.29 exp10 F
+GLIBC_2.29 exp10f F
+GLIBC_2.29 exp10f128 F
+GLIBC_2.29 exp10f32 F
+GLIBC_2.29 exp10f32x F
+GLIBC_2.29 exp10f64 F
+GLIBC_2.29 exp10f64x F
+GLIBC_2.29 exp10l F
+GLIBC_2.29 exp2 F
+GLIBC_2.29 exp2f F
+GLIBC_2.29 exp2f128 F
+GLIBC_2.29 exp2f32 F
+GLIBC_2.29 exp2f32x F
+GLIBC_2.29 exp2f64 F
+GLIBC_2.29 exp2f64x F
+GLIBC_2.29 exp2l F
+GLIBC_2.29 expf F
+GLIBC_2.29 expf128 F
+GLIBC_2.29 expf32 F
+GLIBC_2.29 expf32x F
+GLIBC_2.29 expf64 F
+GLIBC_2.29 expf64x F
+GLIBC_2.29 expl F
+GLIBC_2.29 expm1 F
+GLIBC_2.29 expm1f F
+GLIBC_2.29 expm1f128 F
+GLIBC_2.29 expm1f32 F
+GLIBC_2.29 expm1f32x F
+GLIBC_2.29 expm1f64 F
+GLIBC_2.29 expm1f64x F
+GLIBC_2.29 expm1l F
+GLIBC_2.29 f32addf128 F
+GLIBC_2.29 f32addf32x F
+GLIBC_2.29 f32addf64 F
+GLIBC_2.29 f32addf64x F
+GLIBC_2.29 f32divf128 F
+GLIBC_2.29 f32divf32x F
+GLIBC_2.29 f32divf64 F
+GLIBC_2.29 f32divf64x F
+GLIBC_2.29 f32mulf128 F
+GLIBC_2.29 f32mulf32x F
+GLIBC_2.29 f32mulf64 F
+GLIBC_2.29 f32mulf64x F
+GLIBC_2.29 f32subf128 F
+GLIBC_2.29 f32subf32x F
+GLIBC_2.29 f32subf64 F
+GLIBC_2.29 f32subf64x F
+GLIBC_2.29 f32xaddf128 F
+GLIBC_2.29 f32xaddf64 F
+GLIBC_2.29 f32xaddf64x F
+GLIBC_2.29 f32xdivf128 F
+GLIBC_2.29 f32xdivf64 F
+GLIBC_2.29 f32xdivf64x F
+GLIBC_2.29 f32xmulf128 F
+GLIBC_2.29 f32xmulf64 F
+GLIBC_2.29 f32xmulf64x F
+GLIBC_2.29 f32xsubf128 F
+GLIBC_2.29 f32xsubf64 F
+GLIBC_2.29 f32xsubf64x F
+GLIBC_2.29 f64addf128 F
+GLIBC_2.29 f64addf64x F
+GLIBC_2.29 f64divf128 F
+GLIBC_2.29 f64divf64x F
+GLIBC_2.29 f64mulf128 F
+GLIBC_2.29 f64mulf64x F
+GLIBC_2.29 f64subf128 F
+GLIBC_2.29 f64subf64x F
+GLIBC_2.29 f64xaddf128 F
+GLIBC_2.29 f64xdivf128 F
+GLIBC_2.29 f64xmulf128 F
+GLIBC_2.29 f64xsubf128 F
+GLIBC_2.29 fabs F
+GLIBC_2.29 fabsf F
+GLIBC_2.29 fabsf128 F
+GLIBC_2.29 fabsf32 F
+GLIBC_2.29 fabsf32x F
+GLIBC_2.29 fabsf64 F
+GLIBC_2.29 fabsf64x F
+GLIBC_2.29 fabsl F
+GLIBC_2.29 fadd F
+GLIBC_2.29 faddl F
+GLIBC_2.29 fdim F
+GLIBC_2.29 fdimf F
+GLIBC_2.29 fdimf128 F
+GLIBC_2.29 fdimf32 F
+GLIBC_2.29 fdimf32x F
+GLIBC_2.29 fdimf64 F
+GLIBC_2.29 fdimf64x F
+GLIBC_2.29 fdiml F
+GLIBC_2.29 fdiv F
+GLIBC_2.29 fdivl F
+GLIBC_2.29 feclearexcept F
+GLIBC_2.29 fedisableexcept F
+GLIBC_2.29 feenableexcept F
+GLIBC_2.29 fegetenv F
+GLIBC_2.29 fegetexcept F
+GLIBC_2.29 fegetexceptflag F
+GLIBC_2.29 fegetmode F
+GLIBC_2.29 fegetround F
+GLIBC_2.29 feholdexcept F
+GLIBC_2.29 feraiseexcept F
+GLIBC_2.29 fesetenv F
+GLIBC_2.29 fesetexcept F
+GLIBC_2.29 fesetexceptflag F
+GLIBC_2.29 fesetmode F
+GLIBC_2.29 fesetround F
+GLIBC_2.29 fetestexcept F
+GLIBC_2.29 fetestexceptflag F
+GLIBC_2.29 feupdateenv F
+GLIBC_2.29 finite F
+GLIBC_2.29 finitef F
+GLIBC_2.29 finitel F
+GLIBC_2.29 floor F
+GLIBC_2.29 floorf F
+GLIBC_2.29 floorf128 F
+GLIBC_2.29 floorf32 F
+GLIBC_2.29 floorf32x F
+GLIBC_2.29 floorf64 F
+GLIBC_2.29 floorf64x F
+GLIBC_2.29 floorl F
+GLIBC_2.29 fma F
+GLIBC_2.29 fmaf F
+GLIBC_2.29 fmaf128 F
+GLIBC_2.29 fmaf32 F
+GLIBC_2.29 fmaf32x F
+GLIBC_2.29 fmaf64 F
+GLIBC_2.29 fmaf64x F
+GLIBC_2.29 fmal F
+GLIBC_2.29 fmax F
+GLIBC_2.29 fmaxf F
+GLIBC_2.29 fmaxf128 F
+GLIBC_2.29 fmaxf32 F
+GLIBC_2.29 fmaxf32x F
+GLIBC_2.29 fmaxf64 F
+GLIBC_2.29 fmaxf64x F
+GLIBC_2.29 fmaxl F
+GLIBC_2.29 fmaxmag F
+GLIBC_2.29 fmaxmagf F
+GLIBC_2.29 fmaxmagf128 F
+GLIBC_2.29 fmaxmagf32 F
+GLIBC_2.29 fmaxmagf32x F
+GLIBC_2.29 fmaxmagf64 F
+GLIBC_2.29 fmaxmagf64x F
+GLIBC_2.29 fmaxmagl F
+GLIBC_2.29 fmin F
+GLIBC_2.29 fminf F
+GLIBC_2.29 fminf128 F
+GLIBC_2.29 fminf32 F
+GLIBC_2.29 fminf32x F
+GLIBC_2.29 fminf64 F
+GLIBC_2.29 fminf64x F
+GLIBC_2.29 fminl F
+GLIBC_2.29 fminmag F
+GLIBC_2.29 fminmagf F
+GLIBC_2.29 fminmagf128 F
+GLIBC_2.29 fminmagf32 F
+GLIBC_2.29 fminmagf32x F
+GLIBC_2.29 fminmagf64 F
+GLIBC_2.29 fminmagf64x F
+GLIBC_2.29 fminmagl F
+GLIBC_2.29 fmod F
+GLIBC_2.29 fmodf F
+GLIBC_2.29 fmodf128 F
+GLIBC_2.29 fmodf32 F
+GLIBC_2.29 fmodf32x F
+GLIBC_2.29 fmodf64 F
+GLIBC_2.29 fmodf64x F
+GLIBC_2.29 fmodl F
+GLIBC_2.29 fmul F
+GLIBC_2.29 fmull F
+GLIBC_2.29 frexp F
+GLIBC_2.29 frexpf F
+GLIBC_2.29 frexpf128 F
+GLIBC_2.29 frexpf32 F
+GLIBC_2.29 frexpf32x F
+GLIBC_2.29 frexpf64 F
+GLIBC_2.29 frexpf64x F
+GLIBC_2.29 frexpl F
+GLIBC_2.29 fromfp F
+GLIBC_2.29 fromfpf F
+GLIBC_2.29 fromfpf128 F
+GLIBC_2.29 fromfpf32 F
+GLIBC_2.29 fromfpf32x F
+GLIBC_2.29 fromfpf64 F
+GLIBC_2.29 fromfpf64x F
+GLIBC_2.29 fromfpl F
+GLIBC_2.29 fromfpx F
+GLIBC_2.29 fromfpxf F
+GLIBC_2.29 fromfpxf128 F
+GLIBC_2.29 fromfpxf32 F
+GLIBC_2.29 fromfpxf32x F
+GLIBC_2.29 fromfpxf64 F
+GLIBC_2.29 fromfpxf64x F
+GLIBC_2.29 fromfpxl F
+GLIBC_2.29 fsub F
+GLIBC_2.29 fsubl F
+GLIBC_2.29 gamma F
+GLIBC_2.29 gammaf F
+GLIBC_2.29 gammal F
+GLIBC_2.29 getpayload F
+GLIBC_2.29 getpayloadf F
+GLIBC_2.29 getpayloadf128 F
+GLIBC_2.29 getpayloadf32 F
+GLIBC_2.29 getpayloadf32x F
+GLIBC_2.29 getpayloadf64 F
+GLIBC_2.29 getpayloadf64x F
+GLIBC_2.29 getpayloadl F
+GLIBC_2.29 hypot F
+GLIBC_2.29 hypotf F
+GLIBC_2.29 hypotf128 F
+GLIBC_2.29 hypotf32 F
+GLIBC_2.29 hypotf32x F
+GLIBC_2.29 hypotf64 F
+GLIBC_2.29 hypotf64x F
+GLIBC_2.29 hypotl F
+GLIBC_2.29 ilogb F
+GLIBC_2.29 ilogbf F
+GLIBC_2.29 ilogbf128 F
+GLIBC_2.29 ilogbf32 F
+GLIBC_2.29 ilogbf32x F
+GLIBC_2.29 ilogbf64 F
+GLIBC_2.29 ilogbf64x F
+GLIBC_2.29 ilogbl F
+GLIBC_2.29 j0 F
+GLIBC_2.29 j0f F
+GLIBC_2.29 j0f128 F
+GLIBC_2.29 j0f32 F
+GLIBC_2.29 j0f32x F
+GLIBC_2.29 j0f64 F
+GLIBC_2.29 j0f64x F
+GLIBC_2.29 j0l F
+GLIBC_2.29 j1 F
+GLIBC_2.29 j1f F
+GLIBC_2.29 j1f128 F
+GLIBC_2.29 j1f32 F
+GLIBC_2.29 j1f32x F
+GLIBC_2.29 j1f64 F
+GLIBC_2.29 j1f64x F
+GLIBC_2.29 j1l F
+GLIBC_2.29 jn F
+GLIBC_2.29 jnf F
+GLIBC_2.29 jnf128 F
+GLIBC_2.29 jnf32 F
+GLIBC_2.29 jnf32x F
+GLIBC_2.29 jnf64 F
+GLIBC_2.29 jnf64x F
+GLIBC_2.29 jnl F
+GLIBC_2.29 ldexp F
+GLIBC_2.29 ldexpf F
+GLIBC_2.29 ldexpf128 F
+GLIBC_2.29 ldexpf32 F
+GLIBC_2.29 ldexpf32x F
+GLIBC_2.29 ldexpf64 F
+GLIBC_2.29 ldexpf64x F
+GLIBC_2.29 ldexpl F
+GLIBC_2.29 lgamma F
+GLIBC_2.29 lgamma_r F
+GLIBC_2.29 lgammaf F
+GLIBC_2.29 lgammaf128 F
+GLIBC_2.29 lgammaf128_r F
+GLIBC_2.29 lgammaf32 F
+GLIBC_2.29 lgammaf32_r F
+GLIBC_2.29 lgammaf32x F
+GLIBC_2.29 lgammaf32x_r F
+GLIBC_2.29 lgammaf64 F
+GLIBC_2.29 lgammaf64_r F
+GLIBC_2.29 lgammaf64x F
+GLIBC_2.29 lgammaf64x_r F
+GLIBC_2.29 lgammaf_r F
+GLIBC_2.29 lgammal F
+GLIBC_2.29 lgammal_r F
+GLIBC_2.29 llogb F
+GLIBC_2.29 llogbf F
+GLIBC_2.29 llogbf128 F
+GLIBC_2.29 llogbf32 F
+GLIBC_2.29 llogbf32x F
+GLIBC_2.29 llogbf64 F
+GLIBC_2.29 llogbf64x F
+GLIBC_2.29 llogbl F
+GLIBC_2.29 llrint F
+GLIBC_2.29 llrintf F
+GLIBC_2.29 llrintf128 F
+GLIBC_2.29 llrintf32 F
+GLIBC_2.29 llrintf32x F
+GLIBC_2.29 llrintf64 F
+GLIBC_2.29 llrintf64x F
+GLIBC_2.29 llrintl F
+GLIBC_2.29 llround F
+GLIBC_2.29 llroundf F
+GLIBC_2.29 llroundf128 F
+GLIBC_2.29 llroundf32 F
+GLIBC_2.29 llroundf32x F
+GLIBC_2.29 llroundf64 F
+GLIBC_2.29 llroundf64x F
+GLIBC_2.29 llroundl F
+GLIBC_2.29 log F
+GLIBC_2.29 log10 F
+GLIBC_2.29 log10f F
+GLIBC_2.29 log10f128 F
+GLIBC_2.29 log10f32 F
+GLIBC_2.29 log10f32x F
+GLIBC_2.29 log10f64 F
+GLIBC_2.29 log10f64x F
+GLIBC_2.29 log10l F
+GLIBC_2.29 log1p F
+GLIBC_2.29 log1pf F
+GLIBC_2.29 log1pf128 F
+GLIBC_2.29 log1pf32 F
+GLIBC_2.29 log1pf32x F
+GLIBC_2.29 log1pf64 F
+GLIBC_2.29 log1pf64x F
+GLIBC_2.29 log1pl F
+GLIBC_2.29 log2 F
+GLIBC_2.29 log2f F
+GLIBC_2.29 log2f128 F
+GLIBC_2.29 log2f32 F
+GLIBC_2.29 log2f32x F
+GLIBC_2.29 log2f64 F
+GLIBC_2.29 log2f64x F
+GLIBC_2.29 log2l F
+GLIBC_2.29 logb F
+GLIBC_2.29 logbf F
+GLIBC_2.29 logbf128 F
+GLIBC_2.29 logbf32 F
+GLIBC_2.29 logbf32x F
+GLIBC_2.29 logbf64 F
+GLIBC_2.29 logbf64x F
+GLIBC_2.29 logbl F
+GLIBC_2.29 logf F
+GLIBC_2.29 logf128 F
+GLIBC_2.29 logf32 F
+GLIBC_2.29 logf32x F
+GLIBC_2.29 logf64 F
+GLIBC_2.29 logf64x F
+GLIBC_2.29 logl F
+GLIBC_2.29 lrint F
+GLIBC_2.29 lrintf F
+GLIBC_2.29 lrintf128 F
+GLIBC_2.29 lrintf32 F
+GLIBC_2.29 lrintf32x F
+GLIBC_2.29 lrintf64 F
+GLIBC_2.29 lrintf64x F
+GLIBC_2.29 lrintl F
+GLIBC_2.29 lround F
+GLIBC_2.29 lroundf F
+GLIBC_2.29 lroundf128 F
+GLIBC_2.29 lroundf32 F
+GLIBC_2.29 lroundf32x F
+GLIBC_2.29 lroundf64 F
+GLIBC_2.29 lroundf64x F
+GLIBC_2.29 lroundl F
+GLIBC_2.29 modf F
+GLIBC_2.29 modff F
+GLIBC_2.29 modff128 F
+GLIBC_2.29 modff32 F
+GLIBC_2.29 modff32x F
+GLIBC_2.29 modff64 F
+GLIBC_2.29 modff64x F
+GLIBC_2.29 modfl F
+GLIBC_2.29 nan F
+GLIBC_2.29 nanf F
+GLIBC_2.29 nanf128 F
+GLIBC_2.29 nanf32 F
+GLIBC_2.29 nanf32x F
+GLIBC_2.29 nanf64 F
+GLIBC_2.29 nanf64x F
+GLIBC_2.29 nanl F
+GLIBC_2.29 nearbyint F
+GLIBC_2.29 nearbyintf F
+GLIBC_2.29 nearbyintf128 F
+GLIBC_2.29 nearbyintf32 F
+GLIBC_2.29 nearbyintf32x F
+GLIBC_2.29 nearbyintf64 F
+GLIBC_2.29 nearbyintf64x F
+GLIBC_2.29 nearbyintl F
+GLIBC_2.29 nextafter F
+GLIBC_2.29 nextafterf F
+GLIBC_2.29 nextafterf128 F
+GLIBC_2.29 nextafterf32 F
+GLIBC_2.29 nextafterf32x F
+GLIBC_2.29 nextafterf64 F
+GLIBC_2.29 nextafterf64x F
+GLIBC_2.29 nextafterl F
+GLIBC_2.29 nextdown F
+GLIBC_2.29 nextdownf F
+GLIBC_2.29 nextdownf128 F
+GLIBC_2.29 nextdownf32 F
+GLIBC_2.29 nextdownf32x F
+GLIBC_2.29 nextdownf64 F
+GLIBC_2.29 nextdownf64x F
+GLIBC_2.29 nextdownl F
+GLIBC_2.29 nexttoward F
+GLIBC_2.29 nexttowardf F
+GLIBC_2.29 nexttowardl F
+GLIBC_2.29 nextup F
+GLIBC_2.29 nextupf F
+GLIBC_2.29 nextupf128 F
+GLIBC_2.29 nextupf32 F
+GLIBC_2.29 nextupf32x F
+GLIBC_2.29 nextupf64 F
+GLIBC_2.29 nextupf64x F
+GLIBC_2.29 nextupl F
+GLIBC_2.29 pow F
+GLIBC_2.29 powf F
+GLIBC_2.29 powf128 F
+GLIBC_2.29 powf32 F
+GLIBC_2.29 powf32x F
+GLIBC_2.29 powf64 F
+GLIBC_2.29 powf64x F
+GLIBC_2.29 powl F
+GLIBC_2.29 remainder F
+GLIBC_2.29 remainderf F
+GLIBC_2.29 remainderf128 F
+GLIBC_2.29 remainderf32 F
+GLIBC_2.29 remainderf32x F
+GLIBC_2.29 remainderf64 F
+GLIBC_2.29 remainderf64x F
+GLIBC_2.29 remainderl F
+GLIBC_2.29 remquo F
+GLIBC_2.29 remquof F
+GLIBC_2.29 remquof128 F
+GLIBC_2.29 remquof32 F
+GLIBC_2.29 remquof32x F
+GLIBC_2.29 remquof64 F
+GLIBC_2.29 remquof64x F
+GLIBC_2.29 remquol F
+GLIBC_2.29 rint F
+GLIBC_2.29 rintf F
+GLIBC_2.29 rintf128 F
+GLIBC_2.29 rintf32 F
+GLIBC_2.29 rintf32x F
+GLIBC_2.29 rintf64 F
+GLIBC_2.29 rintf64x F
+GLIBC_2.29 rintl F
+GLIBC_2.29 round F
+GLIBC_2.29 roundeven F
+GLIBC_2.29 roundevenf F
+GLIBC_2.29 roundevenf128 F
+GLIBC_2.29 roundevenf32 F
+GLIBC_2.29 roundevenf32x F
+GLIBC_2.29 roundevenf64 F
+GLIBC_2.29 roundevenf64x F
+GLIBC_2.29 roundevenl F
+GLIBC_2.29 roundf F
+GLIBC_2.29 roundf128 F
+GLIBC_2.29 roundf32 F
+GLIBC_2.29 roundf32x F
+GLIBC_2.29 roundf64 F
+GLIBC_2.29 roundf64x F
+GLIBC_2.29 roundl F
+GLIBC_2.29 scalb F
+GLIBC_2.29 scalbf F
+GLIBC_2.29 scalbl F
+GLIBC_2.29 scalbln F
+GLIBC_2.29 scalblnf F
+GLIBC_2.29 scalblnf128 F
+GLIBC_2.29 scalblnf32 F
+GLIBC_2.29 scalblnf32x F
+GLIBC_2.29 scalblnf64 F
+GLIBC_2.29 scalblnf64x F
+GLIBC_2.29 scalblnl F
+GLIBC_2.29 scalbn F
+GLIBC_2.29 scalbnf F
+GLIBC_2.29 scalbnf128 F
+GLIBC_2.29 scalbnf32 F
+GLIBC_2.29 scalbnf32x F
+GLIBC_2.29 scalbnf64 F
+GLIBC_2.29 scalbnf64x F
+GLIBC_2.29 scalbnl F
+GLIBC_2.29 setpayload F
+GLIBC_2.29 setpayloadf F
+GLIBC_2.29 setpayloadf128 F
+GLIBC_2.29 setpayloadf32 F
+GLIBC_2.29 setpayloadf32x F
+GLIBC_2.29 setpayloadf64 F
+GLIBC_2.29 setpayloadf64x F
+GLIBC_2.29 setpayloadl F
+GLIBC_2.29 setpayloadsig F
+GLIBC_2.29 setpayloadsigf F
+GLIBC_2.29 setpayloadsigf128 F
+GLIBC_2.29 setpayloadsigf32 F
+GLIBC_2.29 setpayloadsigf32x F
+GLIBC_2.29 setpayloadsigf64 F
+GLIBC_2.29 setpayloadsigf64x F
+GLIBC_2.29 setpayloadsigl F
+GLIBC_2.29 signgam D 0x4
+GLIBC_2.29 significand F
+GLIBC_2.29 significandf F
+GLIBC_2.29 significandl F
+GLIBC_2.29 sin F
+GLIBC_2.29 sincos F
+GLIBC_2.29 sincosf F
+GLIBC_2.29 sincosf128 F
+GLIBC_2.29 sincosf32 F
+GLIBC_2.29 sincosf32x F
+GLIBC_2.29 sincosf64 F
+GLIBC_2.29 sincosf64x F
+GLIBC_2.29 sincosl F
+GLIBC_2.29 sinf F
+GLIBC_2.29 sinf128 F
+GLIBC_2.29 sinf32 F
+GLIBC_2.29 sinf32x F
+GLIBC_2.29 sinf64 F
+GLIBC_2.29 sinf64x F
+GLIBC_2.29 sinh F
+GLIBC_2.29 sinhf F
+GLIBC_2.29 sinhf128 F
+GLIBC_2.29 sinhf32 F
+GLIBC_2.29 sinhf32x F
+GLIBC_2.29 sinhf64 F
+GLIBC_2.29 sinhf64x F
+GLIBC_2.29 sinhl F
+GLIBC_2.29 sinl F
+GLIBC_2.29 sqrt F
+GLIBC_2.29 sqrtf F
+GLIBC_2.29 sqrtf128 F
+GLIBC_2.29 sqrtf32 F
+GLIBC_2.29 sqrtf32x F
+GLIBC_2.29 sqrtf64 F
+GLIBC_2.29 sqrtf64x F
+GLIBC_2.29 sqrtl F
+GLIBC_2.29 tan F
+GLIBC_2.29 tanf F
+GLIBC_2.29 tanf128 F
+GLIBC_2.29 tanf32 F
+GLIBC_2.29 tanf32x F
+GLIBC_2.29 tanf64 F
+GLIBC_2.29 tanf64x F
+GLIBC_2.29 tanh F
+GLIBC_2.29 tanhf F
+GLIBC_2.29 tanhf128 F
+GLIBC_2.29 tanhf32 F
+GLIBC_2.29 tanhf32x F
+GLIBC_2.29 tanhf64 F
+GLIBC_2.29 tanhf64x F
+GLIBC_2.29 tanhl F
+GLIBC_2.29 tanl F
+GLIBC_2.29 tgamma F
+GLIBC_2.29 tgammaf F
+GLIBC_2.29 tgammaf128 F
+GLIBC_2.29 tgammaf32 F
+GLIBC_2.29 tgammaf32x F
+GLIBC_2.29 tgammaf64 F
+GLIBC_2.29 tgammaf64x F
+GLIBC_2.29 tgammal F
+GLIBC_2.29 totalorder F
+GLIBC_2.29 totalorderf F
+GLIBC_2.29 totalorderf128 F
+GLIBC_2.29 totalorderf32 F
+GLIBC_2.29 totalorderf32x F
+GLIBC_2.29 totalorderf64 F
+GLIBC_2.29 totalorderf64x F
+GLIBC_2.29 totalorderl F
+GLIBC_2.29 totalordermag F
+GLIBC_2.29 totalordermagf F
+GLIBC_2.29 totalordermagf128 F
+GLIBC_2.29 totalordermagf32 F
+GLIBC_2.29 totalordermagf32x F
+GLIBC_2.29 totalordermagf64 F
+GLIBC_2.29 totalordermagf64x F
+GLIBC_2.29 totalordermagl F
+GLIBC_2.29 trunc F
+GLIBC_2.29 truncf F
+GLIBC_2.29 truncf128 F
+GLIBC_2.29 truncf32 F
+GLIBC_2.29 truncf32x F
+GLIBC_2.29 truncf64 F
+GLIBC_2.29 truncf64x F
+GLIBC_2.29 truncl F
+GLIBC_2.29 ufromfp F
+GLIBC_2.29 ufromfpf F
+GLIBC_2.29 ufromfpf128 F
+GLIBC_2.29 ufromfpf32 F
+GLIBC_2.29 ufromfpf32x F
+GLIBC_2.29 ufromfpf64 F
+GLIBC_2.29 ufromfpf64x F
+GLIBC_2.29 ufromfpl F
+GLIBC_2.29 ufromfpx F
+GLIBC_2.29 ufromfpxf F
+GLIBC_2.29 ufromfpxf128 F
+GLIBC_2.29 ufromfpxf32 F
+GLIBC_2.29 ufromfpxf32x F
+GLIBC_2.29 ufromfpxf64 F
+GLIBC_2.29 ufromfpxf64x F
+GLIBC_2.29 ufromfpxl F
+GLIBC_2.29 y0 F
+GLIBC_2.29 y0f F
+GLIBC_2.29 y0f128 F
+GLIBC_2.29 y0f32 F
+GLIBC_2.29 y0f32x F
+GLIBC_2.29 y0f64 F
+GLIBC_2.29 y0f64x F
+GLIBC_2.29 y0l F
+GLIBC_2.29 y1 F
+GLIBC_2.29 y1f F
+GLIBC_2.29 y1f128 F
+GLIBC_2.29 y1f32 F
+GLIBC_2.29 y1f32x F
+GLIBC_2.29 y1f64 F
+GLIBC_2.29 y1f64x F
+GLIBC_2.29 y1l F
+GLIBC_2.29 yn F
+GLIBC_2.29 ynf F
+GLIBC_2.29 ynf128 F
+GLIBC_2.29 ynf32 F
+GLIBC_2.29 ynf32x F
+GLIBC_2.29 ynf64 F
+GLIBC_2.29 ynf64x F
+GLIBC_2.29 ynl F
diff --git a/sysdeps/unix/sysv/linux/riscv/rv32/libpthread.abilist b/sysdeps/unix/sysv/linux/riscv/rv32/libpthread.abilist
new file mode 100644
index 0000000000..ea4b79a518
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/rv32/libpthread.abilist
@@ -0,0 +1,235 @@
+GLIBC_2.29 _IO_flockfile F
+GLIBC_2.29 _IO_ftrylockfile F
+GLIBC_2.29 _IO_funlockfile F
+GLIBC_2.29 __close F
+GLIBC_2.29 __connect F
+GLIBC_2.29 __errno_location F
+GLIBC_2.29 __h_errno_location F
+GLIBC_2.29 __libc_allocate_rtsig F
+GLIBC_2.29 __libc_current_sigrtmax F
+GLIBC_2.29 __libc_current_sigrtmin F
+GLIBC_2.29 __lseek F
+GLIBC_2.29 __nanosleep F
+GLIBC_2.29 __open F
+GLIBC_2.29 __open64 F
+GLIBC_2.29 __pread64 F
+GLIBC_2.29 __pthread_cleanup_routine F
+GLIBC_2.29 __pthread_getspecific F
+GLIBC_2.29 __pthread_key_create F
+GLIBC_2.29 __pthread_mutex_destroy F
+GLIBC_2.29 __pthread_mutex_init F
+GLIBC_2.29 __pthread_mutex_lock F
+GLIBC_2.29 __pthread_mutex_trylock F
+GLIBC_2.29 __pthread_mutex_unlock F
+GLIBC_2.29 __pthread_mutexattr_destroy F
+GLIBC_2.29 __pthread_mutexattr_init F
+GLIBC_2.29 __pthread_mutexattr_settype F
+GLIBC_2.29 __pthread_once F
+GLIBC_2.29 __pthread_register_cancel F
+GLIBC_2.29 __pthread_register_cancel_defer F
+GLIBC_2.29 __pthread_rwlock_destroy F
+GLIBC_2.29 __pthread_rwlock_init F
+GLIBC_2.29 __pthread_rwlock_rdlock F
+GLIBC_2.29 __pthread_rwlock_tryrdlock F
+GLIBC_2.29 __pthread_rwlock_trywrlock F
+GLIBC_2.29 __pthread_rwlock_unlock F
+GLIBC_2.29 __pthread_rwlock_wrlock F
+GLIBC_2.29 __pthread_setspecific F
+GLIBC_2.29 __pthread_unregister_cancel F
+GLIBC_2.29 __pthread_unregister_cancel_restore F
+GLIBC_2.29 __pthread_unwind_next F
+GLIBC_2.29 __pwrite64 F
+GLIBC_2.29 __read F
+GLIBC_2.29 __res_state F
+GLIBC_2.29 __send F
+GLIBC_2.29 __sigaction F
+GLIBC_2.29 __wait F
+GLIBC_2.29 __write F
+GLIBC_2.29 _pthread_cleanup_pop F
+GLIBC_2.29 _pthread_cleanup_pop_restore F
+GLIBC_2.29 _pthread_cleanup_push F
+GLIBC_2.29 _pthread_cleanup_push_defer F
+GLIBC_2.29 accept F
+GLIBC_2.29 call_once F
+GLIBC_2.29 close F
+GLIBC_2.29 cnd_broadcast F
+GLIBC_2.29 cnd_destroy F
+GLIBC_2.29 cnd_init F
+GLIBC_2.29 cnd_signal F
+GLIBC_2.29 cnd_timedwait F
+GLIBC_2.29 cnd_wait F
+GLIBC_2.29 connect F
+GLIBC_2.29 flockfile F
+GLIBC_2.29 fsync F
+GLIBC_2.29 ftrylockfile F
+GLIBC_2.29 funlockfile F
+GLIBC_2.29 lseek F
+GLIBC_2.29 lseek64 F
+GLIBC_2.29 msync F
+GLIBC_2.29 mtx_destroy F
+GLIBC_2.29 mtx_init F
+GLIBC_2.29 mtx_lock F
+GLIBC_2.29 mtx_timedlock F
+GLIBC_2.29 mtx_trylock F
+GLIBC_2.29 mtx_unlock F
+GLIBC_2.29 nanosleep F
+GLIBC_2.29 open F
+GLIBC_2.29 open64 F
+GLIBC_2.29 pause F
+GLIBC_2.29 pread F
+GLIBC_2.29 pread64 F
+GLIBC_2.29 pthread_attr_destroy F
+GLIBC_2.29 pthread_attr_getaffinity_np F
+GLIBC_2.29 pthread_attr_getdetachstate F
+GLIBC_2.29 pthread_attr_getguardsize F
+GLIBC_2.29 pthread_attr_getinheritsched F
+GLIBC_2.29 pthread_attr_getschedparam F
+GLIBC_2.29 pthread_attr_getschedpolicy F
+GLIBC_2.29 pthread_attr_getscope F
+GLIBC_2.29 pthread_attr_getstack F
+GLIBC_2.29 pthread_attr_getstackaddr F
+GLIBC_2.29 pthread_attr_getstacksize F
+GLIBC_2.29 pthread_attr_init F
+GLIBC_2.29 pthread_attr_setaffinity_np F
+GLIBC_2.29 pthread_attr_setdetachstate F
+GLIBC_2.29 pthread_attr_setguardsize F
+GLIBC_2.29 pthread_attr_setinheritsched F
+GLIBC_2.29 pthread_attr_setschedparam F
+GLIBC_2.29 pthread_attr_setschedpolicy F
+GLIBC_2.29 pthread_attr_setscope F
+GLIBC_2.29 pthread_attr_setstack F
+GLIBC_2.29 pthread_attr_setstackaddr F
+GLIBC_2.29 pthread_attr_setstacksize F
+GLIBC_2.29 pthread_barrier_destroy F
+GLIBC_2.29 pthread_barrier_init F
+GLIBC_2.29 pthread_barrier_wait F
+GLIBC_2.29 pthread_barrierattr_destroy F
+GLIBC_2.29 pthread_barrierattr_getpshared F
+GLIBC_2.29 pthread_barrierattr_init F
+GLIBC_2.29 pthread_barrierattr_setpshared F
+GLIBC_2.29 pthread_cancel F
+GLIBC_2.29 pthread_cond_broadcast F
+GLIBC_2.29 pthread_cond_destroy F
+GLIBC_2.29 pthread_cond_init F
+GLIBC_2.29 pthread_cond_signal F
+GLIBC_2.29 pthread_cond_timedwait F
+GLIBC_2.29 pthread_cond_wait F
+GLIBC_2.29 pthread_condattr_destroy F
+GLIBC_2.29 pthread_condattr_getclock F
+GLIBC_2.29 pthread_condattr_getpshared F
+GLIBC_2.29 pthread_condattr_init F
+GLIBC_2.29 pthread_condattr_setclock F
+GLIBC_2.29 pthread_condattr_setpshared F
+GLIBC_2.29 pthread_create F
+GLIBC_2.29 pthread_detach F
+GLIBC_2.29 pthread_equal F
+GLIBC_2.29 pthread_exit F
+GLIBC_2.29 pthread_getaffinity_np F
+GLIBC_2.29 pthread_getattr_default_np F
+GLIBC_2.29 pthread_getattr_np F
+GLIBC_2.29 pthread_getconcurrency F
+GLIBC_2.29 pthread_getcpuclockid F
+GLIBC_2.29 pthread_getname_np F
+GLIBC_2.29 pthread_getschedparam F
+GLIBC_2.29 pthread_getspecific F
+GLIBC_2.29 pthread_join F
+GLIBC_2.29 pthread_key_create F
+GLIBC_2.29 pthread_key_delete F
+GLIBC_2.29 pthread_kill F
+GLIBC_2.29 pthread_kill_other_threads_np F
+GLIBC_2.29 pthread_mutex_consistent F
+GLIBC_2.29 pthread_mutex_consistent_np F
+GLIBC_2.29 pthread_mutex_destroy F
+GLIBC_2.29 pthread_mutex_getprioceiling F
+GLIBC_2.29 pthread_mutex_init F
+GLIBC_2.29 pthread_mutex_lock F
+GLIBC_2.29 pthread_mutex_setprioceiling F
+GLIBC_2.29 pthread_mutex_timedlock F
+GLIBC_2.29 pthread_mutex_trylock F
+GLIBC_2.29 pthread_mutex_unlock F
+GLIBC_2.29 pthread_mutexattr_destroy F
+GLIBC_2.29 pthread_mutexattr_getkind_np F
+GLIBC_2.29 pthread_mutexattr_getprioceiling F
+GLIBC_2.29 pthread_mutexattr_getprotocol F
+GLIBC_2.29 pthread_mutexattr_getpshared F
+GLIBC_2.29 pthread_mutexattr_getrobust F
+GLIBC_2.29 pthread_mutexattr_getrobust_np F
+GLIBC_2.29 pthread_mutexattr_gettype F
+GLIBC_2.29 pthread_mutexattr_init F
+GLIBC_2.29 pthread_mutexattr_setkind_np F
+GLIBC_2.29 pthread_mutexattr_setprioceiling F
+GLIBC_2.29 pthread_mutexattr_setprotocol F
+GLIBC_2.29 pthread_mutexattr_setpshared F
+GLIBC_2.29 pthread_mutexattr_setrobust F
+GLIBC_2.29 pthread_mutexattr_setrobust_np F
+GLIBC_2.29 pthread_mutexattr_settype F
+GLIBC_2.29 pthread_once F
+GLIBC_2.29 pthread_rwlock_destroy F
+GLIBC_2.29 pthread_rwlock_init F
+GLIBC_2.29 pthread_rwlock_rdlock F
+GLIBC_2.29 pthread_rwlock_timedrdlock F
+GLIBC_2.29 pthread_rwlock_timedwrlock F
+GLIBC_2.29 pthread_rwlock_tryrdlock F
+GLIBC_2.29 pthread_rwlock_trywrlock F
+GLIBC_2.29 pthread_rwlock_unlock F
+GLIBC_2.29 pthread_rwlock_wrlock F
+GLIBC_2.29 pthread_rwlockattr_destroy F
+GLIBC_2.29 pthread_rwlockattr_getkind_np F
+GLIBC_2.29 pthread_rwlockattr_getpshared F
+GLIBC_2.29 pthread_rwlockattr_init F
+GLIBC_2.29 pthread_rwlockattr_setkind_np F
+GLIBC_2.29 pthread_rwlockattr_setpshared F
+GLIBC_2.29 pthread_setaffinity_np F
+GLIBC_2.29 pthread_setattr_default_np F
+GLIBC_2.29 pthread_setcancelstate F
+GLIBC_2.29 pthread_setcanceltype F
+GLIBC_2.29 pthread_setconcurrency F
+GLIBC_2.29 pthread_setname_np F
+GLIBC_2.29 pthread_setschedparam F
+GLIBC_2.29 pthread_setschedprio F
+GLIBC_2.29 pthread_setspecific F
+GLIBC_2.29 pthread_sigmask F
+GLIBC_2.29 pthread_sigqueue F
+GLIBC_2.29 pthread_spin_destroy F
+GLIBC_2.29 pthread_spin_init F
+GLIBC_2.29 pthread_spin_lock F
+GLIBC_2.29 pthread_spin_trylock F
+GLIBC_2.29 pthread_spin_unlock F
+GLIBC_2.29 pthread_testcancel F
+GLIBC_2.29 pthread_timedjoin_np F
+GLIBC_2.29 pthread_tryjoin_np F
+GLIBC_2.29 pthread_yield F
+GLIBC_2.29 pwrite F
+GLIBC_2.29 pwrite64 F
+GLIBC_2.29 raise F
+GLIBC_2.29 read F
+GLIBC_2.29 recv F
+GLIBC_2.29 recvfrom F
+GLIBC_2.29 recvmsg F
+GLIBC_2.29 sem_close F
+GLIBC_2.29 sem_destroy F
+GLIBC_2.29 sem_getvalue F
+GLIBC_2.29 sem_init F
+GLIBC_2.29 sem_open F
+GLIBC_2.29 sem_post F
+GLIBC_2.29 sem_timedwait F
+GLIBC_2.29 sem_trywait F
+GLIBC_2.29 sem_unlink F
+GLIBC_2.29 sem_wait F
+GLIBC_2.29 send F
+GLIBC_2.29 sendmsg F
+GLIBC_2.29 sendto F
+GLIBC_2.29 sigaction F
+GLIBC_2.29 sigwait F
+GLIBC_2.29 tcdrain F
+GLIBC_2.29 thrd_create F
+GLIBC_2.29 thrd_detach F
+GLIBC_2.29 thrd_exit F
+GLIBC_2.29 thrd_join F
+GLIBC_2.29 tss_create F
+GLIBC_2.29 tss_delete F
+GLIBC_2.29 tss_get F
+GLIBC_2.29 tss_set F
+GLIBC_2.29 wait F
+GLIBC_2.29 waitpid F
+GLIBC_2.29 write F
diff --git a/sysdeps/unix/sysv/linux/riscv/rv32/libresolv.abilist b/sysdeps/unix/sysv/linux/riscv/rv32/libresolv.abilist
new file mode 100644
index 0000000000..2830a7efd1
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/rv32/libresolv.abilist
@@ -0,0 +1,79 @@
+GLIBC_2.29 __b64_ntop F
+GLIBC_2.29 __b64_pton F
+GLIBC_2.29 __dn_comp F
+GLIBC_2.29 __dn_count_labels F
+GLIBC_2.29 __dn_expand F
+GLIBC_2.29 __dn_skipname F
+GLIBC_2.29 __fp_nquery F
+GLIBC_2.29 __fp_query F
+GLIBC_2.29 __fp_resstat F
+GLIBC_2.29 __hostalias F
+GLIBC_2.29 __loc_aton F
+GLIBC_2.29 __loc_ntoa F
+GLIBC_2.29 __p_cdname F
+GLIBC_2.29 __p_cdnname F
+GLIBC_2.29 __p_class F
+GLIBC_2.29 __p_class_syms D 0x54
+GLIBC_2.29 __p_fqname F
+GLIBC_2.29 __p_fqnname F
+GLIBC_2.29 __p_option F
+GLIBC_2.29 __p_query F
+GLIBC_2.29 __p_rcode F
+GLIBC_2.29 __p_time F
+GLIBC_2.29 __p_type F
+GLIBC_2.29 __p_type_syms D 0x228
+GLIBC_2.29 __putlong F
+GLIBC_2.29 __putshort F
+GLIBC_2.29 __res_close F
+GLIBC_2.29 __res_dnok F
+GLIBC_2.29 __res_hnok F
+GLIBC_2.29 __res_hostalias F
+GLIBC_2.29 __res_isourserver F
+GLIBC_2.29 __res_mailok F
+GLIBC_2.29 __res_mkquery F
+GLIBC_2.29 __res_nameinquery F
+GLIBC_2.29 __res_nmkquery F
+GLIBC_2.29 __res_nquery F
+GLIBC_2.29 __res_nquerydomain F
+GLIBC_2.29 __res_nsearch F
+GLIBC_2.29 __res_nsend F
+GLIBC_2.29 __res_ownok F
+GLIBC_2.29 __res_queriesmatch F
+GLIBC_2.29 __res_query F
+GLIBC_2.29 __res_querydomain F
+GLIBC_2.29 __res_search F
+GLIBC_2.29 __res_send F
+GLIBC_2.29 __sym_ntop F
+GLIBC_2.29 __sym_ntos F
+GLIBC_2.29 __sym_ston F
+GLIBC_2.29 _getlong F
+GLIBC_2.29 _getshort F
+GLIBC_2.29 inet_net_ntop F
+GLIBC_2.29 inet_net_pton F
+GLIBC_2.29 inet_neta F
+GLIBC_2.29 ns_datetosecs F
+GLIBC_2.29 ns_format_ttl F
+GLIBC_2.29 ns_get16 F
+GLIBC_2.29 ns_get32 F
+GLIBC_2.29 ns_initparse F
+GLIBC_2.29 ns_makecanon F
+GLIBC_2.29 ns_msg_getflag F
+GLIBC_2.29 ns_name_compress F
+GLIBC_2.29 ns_name_ntol F
+GLIBC_2.29 ns_name_ntop F
+GLIBC_2.29 ns_name_pack F
+GLIBC_2.29 ns_name_pton F
+GLIBC_2.29 ns_name_rollback F
+GLIBC_2.29 ns_name_skip F
+GLIBC_2.29 ns_name_uncompress F
+GLIBC_2.29 ns_name_unpack F
+GLIBC_2.29 ns_parse_ttl F
+GLIBC_2.29 ns_parserr F
+GLIBC_2.29 ns_put16 F
+GLIBC_2.29 ns_put32 F
+GLIBC_2.29 ns_samedomain F
+GLIBC_2.29 ns_samename F
+GLIBC_2.29 ns_skiprr F
+GLIBC_2.29 ns_sprintrr F
+GLIBC_2.29 ns_sprintrrf F
+GLIBC_2.29 ns_subdomain F
diff --git a/sysdeps/unix/sysv/linux/riscv/rv32/librt.abilist b/sysdeps/unix/sysv/linux/riscv/rv32/librt.abilist
new file mode 100644
index 0000000000..c6690ef7c1
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/rv32/librt.abilist
@@ -0,0 +1,35 @@
+GLIBC_2.29 __mq_open_2 F
+GLIBC_2.29 aio_cancel F
+GLIBC_2.29 aio_cancel64 F
+GLIBC_2.29 aio_error F
+GLIBC_2.29 aio_error64 F
+GLIBC_2.29 aio_fsync F
+GLIBC_2.29 aio_fsync64 F
+GLIBC_2.29 aio_init F
+GLIBC_2.29 aio_read F
+GLIBC_2.29 aio_read64 F
+GLIBC_2.29 aio_return F
+GLIBC_2.29 aio_return64 F
+GLIBC_2.29 aio_suspend F
+GLIBC_2.29 aio_suspend64 F
+GLIBC_2.29 aio_write F
+GLIBC_2.29 aio_write64 F
+GLIBC_2.29 lio_listio F
+GLIBC_2.29 lio_listio64 F
+GLIBC_2.29 mq_close F
+GLIBC_2.29 mq_getattr F
+GLIBC_2.29 mq_notify F
+GLIBC_2.29 mq_open F
+GLIBC_2.29 mq_receive F
+GLIBC_2.29 mq_send F
+GLIBC_2.29 mq_setattr F
+GLIBC_2.29 mq_timedreceive F
+GLIBC_2.29 mq_timedsend F
+GLIBC_2.29 mq_unlink F
+GLIBC_2.29 shm_open F
+GLIBC_2.29 shm_unlink F
+GLIBC_2.29 timer_create F
+GLIBC_2.29 timer_delete F
+GLIBC_2.29 timer_getoverrun F
+GLIBC_2.29 timer_gettime F
+GLIBC_2.29 timer_settime F
diff --git a/sysdeps/unix/sysv/linux/riscv/rv32/libthread_db.abilist b/sysdeps/unix/sysv/linux/riscv/rv32/libthread_db.abilist
new file mode 100644
index 0000000000..37e9bace55
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/rv32/libthread_db.abilist
@@ -0,0 +1,40 @@
+GLIBC_2.29 td_init F
+GLIBC_2.29 td_log F
+GLIBC_2.29 td_symbol_list F
+GLIBC_2.29 td_ta_clear_event F
+GLIBC_2.29 td_ta_delete F
+GLIBC_2.29 td_ta_enable_stats F
+GLIBC_2.29 td_ta_event_addr F
+GLIBC_2.29 td_ta_event_getmsg F
+GLIBC_2.29 td_ta_get_nthreads F
+GLIBC_2.29 td_ta_get_ph F
+GLIBC_2.29 td_ta_get_stats F
+GLIBC_2.29 td_ta_map_id2thr F
+GLIBC_2.29 td_ta_map_lwp2thr F
+GLIBC_2.29 td_ta_new F
+GLIBC_2.29 td_ta_reset_stats F
+GLIBC_2.29 td_ta_set_event F
+GLIBC_2.29 td_ta_setconcurrency F
+GLIBC_2.29 td_ta_thr_iter F
+GLIBC_2.29 td_ta_tsd_iter F
+GLIBC_2.29 td_thr_clear_event F
+GLIBC_2.29 td_thr_dbresume F
+GLIBC_2.29 td_thr_dbsuspend F
+GLIBC_2.29 td_thr_event_enable F
+GLIBC_2.29 td_thr_event_getmsg F
+GLIBC_2.29 td_thr_get_info F
+GLIBC_2.29 td_thr_getfpregs F
+GLIBC_2.29 td_thr_getgregs F
+GLIBC_2.29 td_thr_getxregs F
+GLIBC_2.29 td_thr_getxregsize F
+GLIBC_2.29 td_thr_set_event F
+GLIBC_2.29 td_thr_setfpregs F
+GLIBC_2.29 td_thr_setgregs F
+GLIBC_2.29 td_thr_setprio F
+GLIBC_2.29 td_thr_setsigpending F
+GLIBC_2.29 td_thr_setxregs F
+GLIBC_2.29 td_thr_sigsetmask F
+GLIBC_2.29 td_thr_tls_get_addr F
+GLIBC_2.29 td_thr_tlsbase F
+GLIBC_2.29 td_thr_tsd F
+GLIBC_2.29 td_thr_validate F
diff --git a/sysdeps/unix/sysv/linux/riscv/rv32/libutil.abilist b/sysdeps/unix/sysv/linux/riscv/rv32/libutil.abilist
new file mode 100644
index 0000000000..cbd11999a4
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/rv32/libutil.abilist
@@ -0,0 +1,6 @@
+GLIBC_2.29 forkpty F
+GLIBC_2.29 login F
+GLIBC_2.29 login_tty F
+GLIBC_2.29 logout F
+GLIBC_2.29 logwtmp F
+GLIBC_2.29 openpty F
-- 
2.22.0

[RFC v2 18/20] RISC-V: Build Infastructure for the 32-bit

[Alistair Francis]

From: Zong Li <zongbox@gmail.com>

This patch lays out the top-level orginazition of the RISC-V 32-bit port. It
contains all the Implies files as well as various other fragments of
build infastructure for the RISC-V 32-bit port.

2018-11-29  Zong Li  <zong@andestech.com>

	* sysdeps/riscv/rv32/Implies-after: New file.
	* sysdeps/riscv/rv32/rvd/Implies: Likewise.
	* sysdeps/riscv/rv32/rvf/Implies: Likewise.
	* sysdeps/unix/sysv/linux/riscv/rv32/Implies: Likewise.
	* sysdeps/unix/sysv/linux/riscv/Makefile: Support rv32.
	* sysdeps/unix/sysv/linux/riscv/configure: Likewise.
	* sysdeps/unix/sysv/linux/riscv/configure.ac: Likewise.
	* sysdeps/unix/sysv/linux/riscv/shlib-versions: Likewise.
	* sysdeps/riscv/preconfigure: Likewise.
---
 ChangeLog                                    |  9 +++++
 sysdeps/riscv/preconfigure                   |  6 +--
 sysdeps/riscv/rv32/Implies-after             |  1 +
 sysdeps/riscv/rv32/rvd/Implies               |  3 ++
 sysdeps/riscv/rv32/rvf/Implies               |  1 +
 sysdeps/unix/sysv/linux/riscv/Makefile       |  4 +-
 sysdeps/unix/sysv/linux/riscv/configure      | 39 ++++++++++++++++++++
 sysdeps/unix/sysv/linux/riscv/configure.ac   |  8 ++++
 sysdeps/unix/sysv/linux/riscv/rv32/Implies   |  3 ++
 sysdeps/unix/sysv/linux/riscv/shlib-versions | 10 ++++-
 10 files changed, 76 insertions(+), 8 deletions(-)
 create mode 100644 sysdeps/riscv/rv32/Implies-after
 create mode 100644 sysdeps/riscv/rv32/rvd/Implies
 create mode 100644 sysdeps/riscv/rv32/rvf/Implies
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/Implies

diff --git a/ChangeLog b/ChangeLog
index 704d425a95..54966f45b8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -82,6 +82,15 @@
 	* sysdeps/unix/sysv/linux/riscv/rv32/libutil.abilist: Likewise.
 	* sysdeps/unix/sysv/linux/riscv/rv32/libBrokenLocale.abilist:
 	Likewise.
+	* sysdeps/riscv/rv32/Implies-after: New file.
+	* sysdeps/riscv/rv32/rvd/Implies: Likewise.
+	* sysdeps/riscv/rv32/rvf/Implies: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/rv32/Implies: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/Makefile: Support rv32.
+	* sysdeps/unix/sysv/linux/riscv/configure: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/configure.ac: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/shlib-versions: Likewise.
+	* sysdeps/riscv/preconfigure: Likewise.
 
 2019-06-20  Dmitry V. Levin  <ldv@altlinux.org>
 	    Florian Weimer  <fweimer@redhat.com>
diff --git a/sysdeps/riscv/preconfigure b/sysdeps/riscv/preconfigure
index d9adb31b64..1ab5d20f0e 100644
--- a/sysdeps/riscv/preconfigure
+++ b/sysdeps/riscv/preconfigure
@@ -6,11 +6,7 @@ riscv*)
     atomic=`$CC $CFLAGS $CPPFLAGS -E -dM -xc /dev/null | grep '#define __riscv_atomic' | cut -d' ' -f2`
 
     case "$xlen" in
-    32)
-	echo "glibc does not yet support 32-bit systems" >&2
-	exit 1
-	;;
-    64)
+    64 | 32)
 	;;
     *)
 	echo "Unable to determine XLEN" >&2
diff --git a/sysdeps/riscv/rv32/Implies-after b/sysdeps/riscv/rv32/Implies-after
new file mode 100644
index 0000000000..39a34c5f57
--- /dev/null
+++ b/sysdeps/riscv/rv32/Implies-after
@@ -0,0 +1 @@
+wordsize-32
diff --git a/sysdeps/riscv/rv32/rvd/Implies b/sysdeps/riscv/rv32/rvd/Implies
new file mode 100644
index 0000000000..1151214e8f
--- /dev/null
+++ b/sysdeps/riscv/rv32/rvd/Implies
@@ -0,0 +1,3 @@
+riscv/rv32/rvf
+riscv/rvd
+riscv/rvf
diff --git a/sysdeps/riscv/rv32/rvf/Implies b/sysdeps/riscv/rv32/rvf/Implies
new file mode 100644
index 0000000000..66c401443b
--- /dev/null
+++ b/sysdeps/riscv/rv32/rvf/Implies
@@ -0,0 +1 @@
+riscv/rvf
diff --git a/sysdeps/unix/sysv/linux/riscv/Makefile b/sysdeps/unix/sysv/linux/riscv/Makefile
index b47858769f..bf9c24ad77 100644
--- a/sysdeps/unix/sysv/linux/riscv/Makefile
+++ b/sysdeps/unix/sysv/linux/riscv/Makefile
@@ -15,11 +15,13 @@ ifeq ($(subdir),stdlib)
 gen-as-const-headers += ucontext_i.sym
 endif
 
-abi-variants := lp64 lp64d
+abi-variants := ilp32 ilp32d lp64 lp64d
 
 ifeq (,$(filter $(default-abi),$(abi-variants)))
 $(error Unknown ABI $(default-abi), must be one of $(abi-variants))
 endif
 
+abi-ilp32-condition   := !defined __LP64__ && defined __riscv_float_abi_soft
+abi-ilp32d-condition  := !defined __LP64__ && defined __riscv_float_abi_double
 abi-lp64-condition    := defined __LP64__ && defined __riscv_float_abi_soft
 abi-lp64d-condition   := defined __LP64__ && defined __riscv_float_abi_double
diff --git a/sysdeps/unix/sysv/linux/riscv/configure b/sysdeps/unix/sysv/linux/riscv/configure
index 3018ca8f1b..2b3c77f18c 100755
--- a/sysdeps/unix/sysv/linux/riscv/configure
+++ b/sysdeps/unix/sysv/linux/riscv/configure
@@ -147,6 +147,17 @@ if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
 fi
 rm -f conftest*
 
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+__SIZEOF_INT__ __SIZEOF_LONG__ __SIZEOF_POINTER__
+
+_ACEOF
+if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
+  $EGREP "4 4 4" >/dev/null 2>&1; then :
+  libc_cv_riscv_int_abi=ilp32
+fi
+rm -f conftest*
+
 if test $libc_cv_riscv_int_abi = no; then
   as_fn_error $? "Unable to determine integer ABI" "$LINENO" 5
 fi
@@ -214,6 +225,34 @@ case "$prefix" in
   ;;
 esac
   ;;
+ilp32-riscv/rv32/*)
+  test -n "$libc_cv_slibdir" ||
+case "$prefix" in
+/usr | /usr/)
+  libc_cv_slibdir='/lib32/ilp32'
+  libc_cv_rtlddir='/lib'
+  if test "$libdir" = '${exec_prefix}/lib'; then
+    libdir='${exec_prefix}/lib32/ilp32';
+    # Locale data can be shared between 32-bit and 64-bit libraries.
+    libc_cv_complocaledir='${exec_prefix}/lib/locale'
+  fi
+  ;;
+esac
+  ;;
+ilp32d-riscv/rv32/*)
+  test -n "$libc_cv_slibdir" ||
+case "$prefix" in
+/usr | /usr/)
+  libc_cv_slibdir='/lib32/ilp32d'
+  libc_cv_rtlddir='/lib'
+  if test "$libdir" = '${exec_prefix}/lib'; then
+    libdir='${exec_prefix}/lib32/ilp32d';
+    # Locale data can be shared between 32-bit and 64-bit libraries.
+    libc_cv_complocaledir='${exec_prefix}/lib/locale'
+  fi
+  ;;
+esac
+  ;;
 esac
 
 ldd_rewrite_script=sysdeps/unix/sysv/linux/riscv/ldd-rewrite.sed
diff --git a/sysdeps/unix/sysv/linux/riscv/configure.ac b/sysdeps/unix/sysv/linux/riscv/configure.ac
index d4819931ca..710d46afcd 100644
--- a/sysdeps/unix/sysv/linux/riscv/configure.ac
+++ b/sysdeps/unix/sysv/linux/riscv/configure.ac
@@ -7,6 +7,8 @@ arch_minimum_kernel=4.15.0
 libc_cv_riscv_int_abi=no
 AC_EGREP_CPP(4 8 8, [__SIZEOF_INT__ __SIZEOF_LONG__ __SIZEOF_POINTER__
   ], libc_cv_riscv_int_abi=lp64)
+AC_EGREP_CPP(4 4 4, [__SIZEOF_INT__ __SIZEOF_LONG__ __SIZEOF_POINTER__
+  ], libc_cv_riscv_int_abi=ilp32)
 if test $libc_cv_riscv_int_abi = no; then
   AC_MSG_ERROR([Unable to determine integer ABI])
 fi
@@ -33,6 +35,12 @@ lp64-riscv/rv64/*)
 lp64d-riscv/rv64/*)
   LIBC_SLIBDIR_RTLDDIR([lib64/lp64d], [lib])
   ;;
+ilp32-riscv/rv32/*)
+  LIBC_SLIBDIR_RTLDDIR([lib32/ilp32], [lib])
+  ;;
+ilp32d-riscv/rv32/*)
+  LIBC_SLIBDIR_RTLDDIR([lib32/ilp32d], [lib])
+  ;;
 esac
 
 ldd_rewrite_script=sysdeps/unix/sysv/linux/riscv/ldd-rewrite.sed
diff --git a/sysdeps/unix/sysv/linux/riscv/rv32/Implies b/sysdeps/unix/sysv/linux/riscv/rv32/Implies
new file mode 100644
index 0000000000..8b7deb33cd
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/rv32/Implies
@@ -0,0 +1,3 @@
+unix/sysv/linux/riscv
+unix/sysv/linux/generic/wordsize-32
+unix/sysv/linux/generic
diff --git a/sysdeps/unix/sysv/linux/riscv/shlib-versions b/sysdeps/unix/sysv/linux/riscv/shlib-versions
index 98c9b29cc4..a767d0f2ef 100644
--- a/sysdeps/unix/sysv/linux/riscv/shlib-versions
+++ b/sysdeps/unix/sysv/linux/riscv/shlib-versions
@@ -1,9 +1,15 @@
-DEFAULT		GLIBC_2.27
-
 %if RISCV_ABI_XLEN == 64 && RISCV_ABI_FLEN == 64
+DEFAULT		GLIBC_2.27
 ld=ld-linux-riscv64-lp64d.so.1
 %elif RISCV_ABI_XLEN == 64 && RISCV_ABI_FLEN == 0
+DEFAULT		GLIBC_2.27
 ld=ld-linux-riscv64-lp64.so.1
+%elif RISCV_ABI_XLEN == 32 && RISCV_ABI_FLEN == 64
+DEFAULT		GLIBC_2.29
+ld=ld-linux-riscv32-ilp32d.so.1
+%elif RISCV_ABI_XLEN == 32 && RISCV_ABI_FLEN == 0
+DEFAULT		GLIBC_2.29
+ld=ld-linux-riscv32-ilp32.so.1
 %else
 %error cannot determine ABI
 %endif
-- 
2.22.0

[RFC v2 19/20] RISC-V: Fix llrint and llround missing exceptions on RV32

[Alistair Francis]

From: Zong Li <zongbox@gmail.com>

Similar to the recent fix for MIPS, ARM and S/390, RV32 is missing
correct exception on overflow from llrint and llround functions because
cast from floating-point types to long long do not result in correct
exceptions on overflow.

2018-11-29  Zong Li  <zong@andestech.com>

	* sysdeps/riscv/rv32/fix-fp-int-convert-overflow.h: New file.
---
 ChangeLog                                     | 10 +++++
 .../riscv/rv32/fix-fp-int-convert-overflow.h  | 38 +++++++++++++++++++
 2 files changed, 48 insertions(+)
 create mode 100644 sysdeps/riscv/rv32/fix-fp-int-convert-overflow.h

diff --git a/ChangeLog b/ChangeLog
index 54966f45b8..f731e94fc9 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -91,6 +91,16 @@
 	* sysdeps/unix/sysv/linux/riscv/configure.ac: Likewise.
 	* sysdeps/unix/sysv/linux/riscv/shlib-versions: Likewise.
 	* sysdeps/riscv/preconfigure: Likewise.
+	* sysdeps/riscv/rv32/Implies-after: New file.
+	* sysdeps/riscv/rv32/rvd/Implies: Likewise.
+	* sysdeps/riscv/rv32/rvf/Implies: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/rv32/Implies: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/Makefile: Support rv32.
+	* sysdeps/unix/sysv/linux/riscv/configure: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/configure.ac: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/shlib-versions: Likewise.
+	* sysdeps/riscv/preconfigure: Likewise.
+	* sysdeps/riscv/rv32/fix-fp-int-convert-overflow.h: New file.
 
 2019-06-20  Dmitry V. Levin  <ldv@altlinux.org>
 	    Florian Weimer  <fweimer@redhat.com>
diff --git a/sysdeps/riscv/rv32/fix-fp-int-convert-overflow.h b/sysdeps/riscv/rv32/fix-fp-int-convert-overflow.h
new file mode 100644
index 0000000000..6b34a8415e
--- /dev/null
+++ b/sysdeps/riscv/rv32/fix-fp-int-convert-overflow.h
@@ -0,0 +1,38 @@
+/* Fix for conversion of floating point to integer overflow.  ARM version.
+   Copyright (C) 2015-2018 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <http://www.gnu.org/licenses/>.  */
+
+#ifndef FIX_FP_INT_CONVERT_OVERFLOW_H
+#define FIX_FP_INT_CONVERT_OVERFLOW_H	1
+
+/* As of GCC 5, the generic libgcc2.c conversions from floating point
+   to long long may not raise the correct exceptions on overflow (and
+   may raise spurious "inexact" exceptions even in non-overflow cases,
+   see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59412>).  */
+#define FIX_FLT_LONG_CONVERT_OVERFLOW 0
+#define FIX_FLT_LLONG_CONVERT_OVERFLOW 1
+
+#define FIX_DBL_LONG_CONVERT_OVERFLOW 0
+#define FIX_DBL_LLONG_CONVERT_OVERFLOW 1
+
+#define FIX_LDBL_LONG_CONVERT_OVERFLOW 0
+#define FIX_LDBL_LLONG_CONVERT_OVERFLOW 0
+
+#define FIX_FLT128_LONG_CONVERT_OVERFLOW 0
+#define FIX_FLT128_LLONG_CONVERT_OVERFLOW 0
+
+#endif /* fix-fp-int-convert-overflow.h */
-- 
2.22.0

[RFC v2 20/20] Add RISC-V 32-bit target to build-many-glibcs.py

[Alistair Francis]

From: Zong Li <zongbox@gmail.com>

Support building three variant of 32 bit RISC-V glibc as follows:
- riscv32-linux-gnu-rv32imac-ilp32
- riscv32-linux-gnu-rv32imafdc-ilp32
- riscv32-linux-gnu-rv32imafdc-ilp32d

2018-11-29  Zong Li  <zong@andestech.com>

	* scripts/build-many-glibcs.py (Context): Add rv32 targets.
---
 ChangeLog                    | 11 +++++++++++
 scripts/build-many-glibcs.py | 15 +++++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index f731e94fc9..b18e9730bc 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -101,6 +101,17 @@
 	* sysdeps/unix/sysv/linux/riscv/shlib-versions: Likewise.
 	* sysdeps/riscv/preconfigure: Likewise.
 	* sysdeps/riscv/rv32/fix-fp-int-convert-overflow.h: New file.
+	* sysdeps/riscv/rv32/Implies-after: New file.
+	* sysdeps/riscv/rv32/rvd/Implies: Likewise.
+	* sysdeps/riscv/rv32/rvf/Implies: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/rv32/Implies: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/Makefile: Support rv32.
+	* sysdeps/unix/sysv/linux/riscv/configure: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/configure.ac: Likewise.
+	* sysdeps/unix/sysv/linux/riscv/shlib-versions: Likewise.
+	* sysdeps/riscv/preconfigure: Likewise.
+	* sysdeps/riscv/rv32/fix-fp-int-convert-overflow.h: New file.
+	* scripts/build-many-glibcs.py (Context): Add rv32 targets.
 
 2019-06-20  Dmitry V. Levin  <ldv@altlinux.org>
 	    Florian Weimer  <fweimer@redhat.com>
diff --git a/scripts/build-many-glibcs.py b/scripts/build-many-glibcs.py
index c5821df25e..5923371149 100755
--- a/scripts/build-many-glibcs.py
+++ b/scripts/build-many-glibcs.py
@@ -318,6 +318,21 @@ class Context(object):
         self.add_config(arch='powerpc64le',
                         os_name='linux-gnu',
                         gcc_cfg=['--disable-multilib', '--enable-secureplt'])
+        self.add_config(arch='riscv32',
+                        os_name='linux-gnu',
+                        variant='rv32imac-ilp32',
+                        gcc_cfg=['--with-arch=rv32imac', '--with-abi=ilp32',
+                                 '--disable-multilib'])
+        self.add_config(arch='riscv32',
+                        os_name='linux-gnu',
+                        variant='rv32imafdc-ilp32',
+                        gcc_cfg=['--with-arch=rv32imafdc', '--with-abi=ilp32',
+                                 '--disable-multilib'])
+        self.add_config(arch='riscv32',
+                        os_name='linux-gnu',
+                        variant='rv32imafdc-ilp32d',
+                        gcc_cfg=['--with-arch=rv32imafdc', '--with-abi=ilp32d',
+                                 '--disable-multilib'])
         self.add_config(arch='riscv64',
                         os_name='linux-gnu',
                         variant='rv64imac-lp64',
-- 
2.22.0

Re: [RFC v2 00/20] RISC-V glibc port for the 32-bit

[Florian Weimer]

* Alistair Francis:

> To mitigate this I have set the RV32 port to use 64-bit time_t and off_t
> (as is done in x86-32) and also changed the syscall imvocation to handle
> the missing syscalls.
>
> The first 3 patches are from Lukasz and have been sent upstream before
> [2].
>
> The 4th patch is a fixup required ontop of Lukasz's patches.

I think if the port has a 64-bit time_t only, you really should not need
Lukasz's patches.  What's problematic about the x86-64 x32 approach?

Thanks,
Florian

Re: [RFC v2 00/20] RISC-V glibc port for the 32-bit

[Arnd Bergmann]

On Tue, Jun 25, 2019 at 1:16 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Alistair Francis:
>
> > To mitigate this I have set the RV32 port to use 64-bit time_t and off_t
> > (as is done in x86-32) and also changed the syscall imvocation to handle
> > the missing syscalls.
> >
> > The first 3 patches are from Lukasz and have been sent upstream before
> > [2].
> >
> > The 4th patch is a fixup required ontop of Lukasz's patches.
>
> I think if the port has a 64-bit time_t only, you really should not need
> Lukasz's patches.  What's problematic about the x86-64 x32 approach?

x32 is really different from everything else at the kernel level. It's
an odd mix of the old __NR_* macros with data structures from the
64-bit kernel, while rv32 behaves just like all the other architectures
as long as you use the new data types. I would hope that nds32
and rv32 can implement the syscall interface in the same way,
and all future glibc ports can follow that. This will also share all the
code with the existing 32-bit architectures except that those
need a runtime fallback (until you stop stupporting kernels earlier
than linux-5.1, maybe in 5 to 10 years from now?).

      Arnd

Re: [RFC v2 00/20] RISC-V glibc port for the 32-bit

[Jim Wilson]

On Tue, Jun 25, 2019 at 8:11 AM Alistair Francis
<alistair.francis@wdc.com> wrote:
> This is based on all of the work that Zong Li has done [1].

FYI Zong Li works for SiFive now.  I added his new email address to
the cc-list.  I don't know if he will have much time to help though,
as he has already been given a development assignment.

Jim