* [RFC v6 01/23] math/gen-libm-test.py: Convert to Python 3
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
@ 2020-01-12 10:33 ` Alistair Francis
2020-01-12 14:46 ` Joseph Myers
2020-01-12 10:33 ` [RFC v6 02/23] tst-clone3: Use __NR_futex_time64 if we don't have __NR_futex Alistair Francis
` (22 subsequent siblings)
23 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:33 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
Convert to explicity use Python 3. This was tested by using the script
(with Python 3) to generate the RV32 libm-test-ulps.
---
math/gen-libm-test.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/math/gen-libm-test.py b/math/gen-libm-test.py
index ec263397d8..0142c0f332 100755
--- a/math/gen-libm-test.py
+++ b/math/gen-libm-test.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/python3
# Generate tests for libm functions.
# Copyright (C) 2018-2020 Free Software Foundation, Inc.
# This file is part of the GNU C Library.
--
2.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* Re: [RFC v6 01/23] math/gen-libm-test.py: Convert to Python 3
2020-01-12 10:33 ` [RFC v6 01/23] math/gen-libm-test.py: Convert to Python 3 Alistair Francis
@ 2020-01-12 14:46 ` Joseph Myers
2020-01-14 6:53 ` Alistair Francis
0 siblings, 1 reply; 138+ messages in thread
From: Joseph Myers @ 2020-01-12 14:46 UTC (permalink / raw)
To: Alistair Francis
Cc: libc-alpha, arnd, adhemerval.zanella, fweimer, palmerdabbelt,
macro, zongbox, alistair23
On Sun, 12 Jan 2020, Alistair Francis wrote:
> Convert to explicity use Python 3. This was tested by using the script
> (with Python 3) to generate the RV32 libm-test-ulps.
There are several .py scripts in the source tree that reference
/usr/bin/python. It doesn't normally matter because the makefiles
explicitly use $(PYTHON), but I think you should change all ten such .py
files at once to refer to python3.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 01/23] math/gen-libm-test.py: Convert to Python 3
2020-01-12 14:46 ` Joseph Myers
@ 2020-01-14 6:53 ` Alistair Francis
0 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-14 6:53 UTC (permalink / raw)
To: Joseph Myers
Cc: Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Mon, Jan 13, 2020 at 12:46 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Sun, 12 Jan 2020, Alistair Francis wrote:
>
> > Convert to explicity use Python 3. This was tested by using the script
> > (with Python 3) to generate the RV32 libm-test-ulps.
>
> There are several .py scripts in the source tree that reference
> /usr/bin/python. It doesn't normally matter because the makefiles
> explicitly use $(PYTHON), but I think you should change all ten such .py
> files at once to refer to python3.
I have updated all of them, the only problem is then that I haven't
tested them all.
Alistair
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* [RFC v6 02/23] tst-clone3: Use __NR_futex_time64 if we don't have __NR_futex
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
2020-01-12 10:33 ` [RFC v6 01/23] math/gen-libm-test.py: Convert to Python 3 Alistair Francis
@ 2020-01-12 10:33 ` Alistair Francis
2020-01-12 10:33 ` [RFC v6 03/23] time: Add a timeval with a long tv_sec and tv_usec Alistair Francis
` (21 subsequent siblings)
23 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:33 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
We can't include sysdep.h in the test case (it introduces lots of
strange failures) so __NR_futex isn't redifined to __NR_futex_time64 by
64-bit time_t 32-bit archs (y2038 safe).
To allow the test to pass let's just do the __NR_futex_time64 syscall if
we don't have __NR_futex defined.
---
sysdeps/unix/sysv/linux/tst-clone3.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/sysdeps/unix/sysv/linux/tst-clone3.c b/sysdeps/unix/sysv/linux/tst-clone3.c
index 400eb89a5b..613cb4a811 100644
--- a/sysdeps/unix/sysv/linux/tst-clone3.c
+++ b/sysdeps/unix/sysv/linux/tst-clone3.c
@@ -56,7 +56,11 @@ f (void *a)
static inline int
futex_wait (int *futexp, int val)
{
+#ifdef __NR_futex
return syscall (__NR_futex, futexp, FUTEX_WAIT, val);
+#else
+ return syscall (__NR_futex_time64, futexp, FUTEX_WAIT, val);
+#endif
}
static int
--
2.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* [RFC v6 03/23] time: Add a timeval with a long tv_sec and tv_usec
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
2020-01-12 10:33 ` [RFC v6 01/23] math/gen-libm-test.py: Convert to Python 3 Alistair Francis
2020-01-12 10:33 ` [RFC v6 02/23] tst-clone3: Use __NR_futex_time64 if we don't have __NR_futex Alistair Francis
@ 2020-01-12 10:33 ` Alistair Francis
2020-01-12 14:48 ` Joseph Myers
2020-01-14 10:16 ` Lukasz Majewski
2020-01-12 10:33 ` [RFC v6 04/23] linux: Use 32-bit time_t for itimerval Alistair Francis
` (20 subsequent siblings)
23 siblings, 2 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:33 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
On y2038 safe 32-bit systems the Linux kernel expects itimerval to
use a 32-bit time_t, even though the other time_t's are 64-bit. To
address this let's add a timeval_long struct to be used internally.
---
include/time.h | 29 +++++++++++++++++++++++++++++
time/bits/types/struct_timeval.h | 8 ++++++++
2 files changed, 37 insertions(+)
diff --git a/include/time.h b/include/time.h
index e5e8246eac..201342d1ca 100644
--- a/include/time.h
+++ b/include/time.h
@@ -310,6 +310,35 @@ valid_timespec64_to_timeval (const struct __timespec64 ts64)
return tv;
}
+/* Conversion functions for converting to/from __timeval_long
+. If the seconds field of a __timeval_long would
+ overflow, they write { INT32_MAX, 999999 } to the output. */
+static inline struct timeval
+valid_timeval_long_to_timeval64 (const struct __timeval_long tv)
+{
+ return (struct timeval) { tv.tv_sec, tv.tv_usec };
+}
+
+static inline struct __timeval_long
+valid_timeval64_to_timeval_long (const struct timeval tv64)
+{
+ if (__glibc_unlikely (tv64.tv_sec > (time_t) 2147483647))
+ return (struct __timeval_long) { 2147483647, 999999};
+ return (struct __timeval_long) { tv64.tv_sec, tv64.tv_usec };
+}
+
+static inline struct timespec
+valid_timeval_long_to_timespec (const struct __timeval_long tv)
+{
+ return (struct timespec) { tv.tv_sec, tv.tv_usec * 1000 };
+}
+
+static inline struct __timeval_long
+valid_timespec_to_timeval_long (const struct timespec ts)
+{
+ return (struct __timeval_long) { (time_t) ts.tv_sec, ts.tv_nsec / 1000 };
+}
+
/* Check if a value is in the valid nanoseconds range. Return true if
it is, false otherwise. */
static inline bool
diff --git a/time/bits/types/struct_timeval.h b/time/bits/types/struct_timeval.h
index 70394ce886..73697689cc 100644
--- a/time/bits/types/struct_timeval.h
+++ b/time/bits/types/struct_timeval.h
@@ -10,4 +10,12 @@ struct timeval
__time_t tv_sec; /* Seconds. */
__suseconds_t tv_usec; /* Microseconds. */
};
+
+/* A version of 'struct timeval' with `long` time_t
+ and suseconds_t. */
+struct __timeval_long
+{
+ long tv_sec; /* Seconds. */
+ long tv_usec; /* Microseconds. */
+};
#endif
--
2.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* Re: [RFC v6 03/23] time: Add a timeval with a long tv_sec and tv_usec
2020-01-12 10:33 ` [RFC v6 03/23] time: Add a timeval with a long tv_sec and tv_usec Alistair Francis
@ 2020-01-12 14:48 ` Joseph Myers
2020-01-14 7:18 ` Alistair Francis
2020-01-14 10:16 ` Lukasz Majewski
1 sibling, 1 reply; 138+ messages in thread
From: Joseph Myers @ 2020-01-12 14:48 UTC (permalink / raw)
To: Alistair Francis
Cc: libc-alpha, arnd, adhemerval.zanella, fweimer, palmerdabbelt,
macro, zongbox, alistair23
On Sun, 12 Jan 2020, Alistair Francis wrote:
> On y2038 safe 32-bit systems the Linux kernel expects itimerval to
> use a 32-bit time_t, even though the other time_t's are 64-bit. To
> address this let's add a timeval_long struct to be used internally.
> ---
> include/time.h | 29 +++++++++++++++++++++++++++++
> time/bits/types/struct_timeval.h | 8 ++++++++
bits/types/ headers are *installed* headers that should only define the
type in question. If there is some good reason to need __timeval_long in
*installed* headers (i.e. a *public* interface using this type) it should
go in bits/types/struct___timeval_long.h, otherwise it should go in a
non-installed header.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 03/23] time: Add a timeval with a long tv_sec and tv_usec
2020-01-12 14:48 ` Joseph Myers
@ 2020-01-14 7:18 ` Alistair Francis
2020-01-14 11:27 ` Lukasz Majewski
0 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-01-14 7:18 UTC (permalink / raw)
To: Joseph Myers
Cc: Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Mon, Jan 13, 2020 at 12:48 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Sun, 12 Jan 2020, Alistair Francis wrote:
>
> > On y2038 safe 32-bit systems the Linux kernel expects itimerval to
> > use a 32-bit time_t, even though the other time_t's are 64-bit. To
> > address this let's add a timeval_long struct to be used internally.
> > ---
> > include/time.h | 29 +++++++++++++++++++++++++++++
> > time/bits/types/struct_timeval.h | 8 ++++++++
>
> bits/types/ headers are *installed* headers that should only define the
> type in question. If there is some good reason to need __timeval_long in
> *installed* headers (i.e. a *public* interface using this type) it should
> go in bits/types/struct___timeval_long.h, otherwise it should go in a
> non-installed header.
Ok, I don't think this should be installed. The only possible reason
installing this would be if someone was manually calling the syscalls
and wanted to use this type to do that.
Do you have a recommendation of a non installed header where it should go?
Alistair
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 03/23] time: Add a timeval with a long tv_sec and tv_usec
2020-01-14 7:18 ` Alistair Francis
@ 2020-01-14 11:27 ` Lukasz Majewski
0 siblings, 0 replies; 138+ messages in thread
From: Lukasz Majewski @ 2020-01-14 11:27 UTC (permalink / raw)
To: Alistair Francis, Joseph Myers
Cc: Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]
Hi Alistair,
> On Mon, Jan 13, 2020 at 12:48 AM Joseph Myers
> <joseph@codesourcery.com> wrote:
> >
> > On Sun, 12 Jan 2020, Alistair Francis wrote:
> >
> > > On y2038 safe 32-bit systems the Linux kernel expects itimerval to
> > > use a 32-bit time_t, even though the other time_t's are 64-bit. To
> > > address this let's add a timeval_long struct to be used
> > > internally. ---
> > > include/time.h | 29
> > > +++++++++++++++++++++++++++++ time/bits/types/struct_timeval.h |
> > > 8 ++++++++
> >
> > bits/types/ headers are *installed* headers that should only define
> > the type in question. If there is some good reason to need
> > __timeval_long in *installed* headers (i.e. a *public* interface
> > using this type) it should go in
> > bits/types/struct___timeval_long.h, otherwise it should go in a
> > non-installed header.
>
> Ok, I don't think this should be installed. The only possible reason
> installing this would be if someone was manually calling the syscalls
> and wanted to use this type to do that.
>
> Do you have a recommendation of a non installed header where it
> should go?
I'm not sure if this hint will match your use case, but similar:
struct __timespec64 and struct __itimerspec64 are defined in
./include/time.h
This is the place for glibc internal definitions (not
installed/exported).
>
> Alistair
>
> >
> > --
> > Joseph S. Myers
> > joseph@codesourcery.com
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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 03/23] time: Add a timeval with a long tv_sec and tv_usec
2020-01-12 10:33 ` [RFC v6 03/23] time: Add a timeval with a long tv_sec and tv_usec Alistair Francis
2020-01-12 14:48 ` Joseph Myers
@ 2020-01-14 10:16 ` Lukasz Majewski
2020-01-15 5:15 ` Alistair Francis
1 sibling, 1 reply; 138+ messages in thread
From: Lukasz Majewski @ 2020-01-14 10:16 UTC (permalink / raw)
To: Alistair Francis
Cc: libc-alpha, arnd, adhemerval.zanella, fweimer, joseph,
palmerdabbelt, macro, zongbox, alistair23, Adhemerval Zanella,
Zack Weinberg
[-- Attachment #1: Type: text/plain, Size: 2978 bytes --]
Hi Alistair,
> On y2038 safe 32-bit systems the Linux kernel expects itimerval to
> use a 32-bit time_t, even though the other time_t's are 64-bit. To
> address this let's add a timeval_long
^^^^^^^^^^^^^ - I'm not so seasoned glibc
developer, but I think that the _long suffix
is a bit misleading.
Maybe it would be more readable to name it as struct
__timeval32 ? In that way one can see from the outset that we
operate on 32 bit values.
Community feedback is welcome :-)
> struct to be used internally.
> ---
> include/time.h | 29 +++++++++++++++++++++++++++++
> time/bits/types/struct_timeval.h | 8 ++++++++
> 2 files changed, 37 insertions(+)
>
> diff --git a/include/time.h b/include/time.h
> index e5e8246eac..201342d1ca 100644
> --- a/include/time.h
> +++ b/include/time.h
> @@ -310,6 +310,35 @@ valid_timespec64_to_timeval (const struct
> __timespec64 ts64) return tv;
> }
>
> +/* Conversion functions for converting to/from __timeval_long
> +. If the seconds field of a __timeval_long would
> + overflow, they write { INT32_MAX, 999999 } to the output. */
> +static inline struct timeval
> +valid_timeval_long_to_timeval64 (const struct __timeval_long tv)
> +{
> + return (struct timeval) { tv.tv_sec, tv.tv_usec };
> +}
> +
> +static inline struct __timeval_long
> +valid_timeval64_to_timeval_long (const struct timeval tv64)
> +{
> + if (__glibc_unlikely (tv64.tv_sec > (time_t) 2147483647))
> + return (struct __timeval_long) { 2147483647, 999999};
> + return (struct __timeval_long) { tv64.tv_sec, tv64.tv_usec };
> +}
> +
> +static inline struct timespec
> +valid_timeval_long_to_timespec (const struct __timeval_long tv)
> +{
> + return (struct timespec) { tv.tv_sec, tv.tv_usec * 1000 };
> +}
> +
> +static inline struct __timeval_long
> +valid_timespec_to_timeval_long (const struct timespec ts)
> +{
> + return (struct __timeval_long) { (time_t) ts.tv_sec, ts.tv_nsec /
> 1000 }; +}
> +
> /* Check if a value is in the valid nanoseconds range. Return true if
> it is, false otherwise. */
> static inline bool
> diff --git a/time/bits/types/struct_timeval.h
> b/time/bits/types/struct_timeval.h index 70394ce886..73697689cc 100644
> --- a/time/bits/types/struct_timeval.h
> +++ b/time/bits/types/struct_timeval.h
> @@ -10,4 +10,12 @@ struct timeval
> __time_t tv_sec; /* Seconds. */
> __suseconds_t tv_usec; /* Microseconds. */
> };
> +
> +/* A version of 'struct timeval' with `long` time_t
> + and suseconds_t. */
> +struct __timeval_long
> +{
> + long tv_sec; /* Seconds. */
> + long tv_usec; /* Microseconds. */
> +};
> #endif
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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 03/23] time: Add a timeval with a long tv_sec and tv_usec
2020-01-14 10:16 ` Lukasz Majewski
@ 2020-01-15 5:15 ` Alistair Francis
2020-01-15 8:01 ` Arnd Bergmann
2020-01-15 8:48 ` Lukasz Majewski
0 siblings, 2 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-15 5:15 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Alistair Francis, GNU C Library, Arnd Bergmann, Florian Weimer,
Joseph Myers, Palmer Dabbelt, Maciej W. Rozycki, Zong Li,
Adhemerval Zanella, Zack Weinberg
On Tue, Jan 14, 2020 at 8:17 PM Lukasz Majewski <lukma@denx.de> wrote:
>
> Hi Alistair,
>
> > On y2038 safe 32-bit systems the Linux kernel expects itimerval to
> > use a 32-bit time_t, even though the other time_t's are 64-bit. To
> > address this let's add a timeval_long
> ^^^^^^^^^^^^^ - I'm not so seasoned glibc
> developer, but I think that the _long suffix
> is a bit misleading.
>
> Maybe it would be more readable to name it as struct
> __timeval32 ? In that way one can see from the outset that we
> operate on 32 bit values.
It isn't explicitly 32-bit, it's just always a long which is why I
went with long in the name instead.
I'm happy to change the name, it doesn't really matter too much as
it's only user internally.
I'll wait to see what others think before changing it.
Alistair
>
> Community feedback is welcome :-)
>
> > struct to be used internally.
> > ---
> > include/time.h | 29 +++++++++++++++++++++++++++++
> > time/bits/types/struct_timeval.h | 8 ++++++++
> > 2 files changed, 37 insertions(+)
> >
> > diff --git a/include/time.h b/include/time.h
> > index e5e8246eac..201342d1ca 100644
> > --- a/include/time.h
> > +++ b/include/time.h
> > @@ -310,6 +310,35 @@ valid_timespec64_to_timeval (const struct
> > __timespec64 ts64) return tv;
> > }
> >
> > +/* Conversion functions for converting to/from __timeval_long
> > +. If the seconds field of a __timeval_long would
> > + overflow, they write { INT32_MAX, 999999 } to the output. */
> > +static inline struct timeval
> > +valid_timeval_long_to_timeval64 (const struct __timeval_long tv)
> > +{
> > + return (struct timeval) { tv.tv_sec, tv.tv_usec };
> > +}
> > +
> > +static inline struct __timeval_long
> > +valid_timeval64_to_timeval_long (const struct timeval tv64)
> > +{
> > + if (__glibc_unlikely (tv64.tv_sec > (time_t) 2147483647))
> > + return (struct __timeval_long) { 2147483647, 999999};
> > + return (struct __timeval_long) { tv64.tv_sec, tv64.tv_usec };
> > +}
> > +
> > +static inline struct timespec
> > +valid_timeval_long_to_timespec (const struct __timeval_long tv)
> > +{
> > + return (struct timespec) { tv.tv_sec, tv.tv_usec * 1000 };
> > +}
> > +
> > +static inline struct __timeval_long
> > +valid_timespec_to_timeval_long (const struct timespec ts)
> > +{
> > + return (struct __timeval_long) { (time_t) ts.tv_sec, ts.tv_nsec /
> > 1000 }; +}
> > +
> > /* Check if a value is in the valid nanoseconds range. Return true if
> > it is, false otherwise. */
> > static inline bool
> > diff --git a/time/bits/types/struct_timeval.h
> > b/time/bits/types/struct_timeval.h index 70394ce886..73697689cc 100644
> > --- a/time/bits/types/struct_timeval.h
> > +++ b/time/bits/types/struct_timeval.h
> > @@ -10,4 +10,12 @@ struct timeval
> > __time_t tv_sec; /* Seconds. */
> > __suseconds_t tv_usec; /* Microseconds. */
> > };
> > +
> > +/* A version of 'struct timeval' with `long` time_t
> > + and suseconds_t. */
> > +struct __timeval_long
> > +{
> > + long tv_sec; /* Seconds. */
> > + long tv_usec; /* Microseconds. */
> > +};
> > #endif
>
> 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
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 03/23] time: Add a timeval with a long tv_sec and tv_usec
2020-01-15 5:15 ` Alistair Francis
@ 2020-01-15 8:01 ` Arnd Bergmann
2020-01-15 8:48 ` Lukasz Majewski
1 sibling, 0 replies; 138+ messages in thread
From: Arnd Bergmann @ 2020-01-15 8:01 UTC (permalink / raw)
To: Alistair Francis
Cc: Lukasz Majewski, Alistair Francis, GNU C Library, Florian Weimer,
Joseph Myers, Palmer Dabbelt, Maciej W. Rozycki, Zong Li,
Adhemerval Zanella, Zack Weinberg
On Wed, Jan 15, 2020 at 6:15 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Tue, Jan 14, 2020 at 8:17 PM Lukasz Majewski <lukma@denx.de> wrote:
> >
> > Hi Alistair,
> >
> > > On y2038 safe 32-bit systems the Linux kernel expects itimerval to
> > > use a 32-bit time_t, even though the other time_t's are 64-bit. To
> > > address this let's add a timeval_long
> > ^^^^^^^^^^^^^ - I'm not so seasoned glibc
> > developer, but I think that the _long suffix
> > is a bit misleading.
> >
> > Maybe it would be more readable to name it as struct
> > __timeval32 ? In that way one can see from the outset that we
> > operate on 32 bit values.
>
> It isn't explicitly 32-bit, it's just always a long which is why I
> went with long in the name instead.
>
> I'm happy to change the name, it doesn't really matter too much as
> it's only user internally.
>
> I'll wait to see what others think before changing it.
I think you can look at it either way: the Your timeval_long works fine
on both 32-bit and 64-bit architectures, but you really only need it
on 32-bit ones because on 64-bit architectures (except sparc64, which
has 32-bit suseconds_t !) this is the same as the default timeval
anyway.
In the kernel we actually ended up having both: there is a
"struct __kernel_old_timeval" that is part of the uapi headers
for defining structures based on the old type with no replacement
such as rusage and itimerval, and internally there is a "struct
old_timeval32" with two "int32_t" members that is used for
providing compatibility handlers for old interfaces that have a
64-bit replacement, so the same compatibility handler can be
used on native 32-bit kernels and on 64-bit kernels running
32-bit user space.
Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 03/23] time: Add a timeval with a long tv_sec and tv_usec
2020-01-15 5:15 ` Alistair Francis
2020-01-15 8:01 ` Arnd Bergmann
@ 2020-01-15 8:48 ` Lukasz Majewski
1 sibling, 0 replies; 138+ messages in thread
From: Lukasz Majewski @ 2020-01-15 8:48 UTC (permalink / raw)
To: Alistair Francis
Cc: Alistair Francis, GNU C Library, Arnd Bergmann, Florian Weimer,
Joseph Myers, Palmer Dabbelt, Maciej W. Rozycki, Zong Li,
Adhemerval Zanella, Zack Weinberg
[-- Attachment #1: Type: text/plain, Size: 4176 bytes --]
Hi Alistair,
> On Tue, Jan 14, 2020 at 8:17 PM Lukasz Majewski <lukma@denx.de> wrote:
> >
> > Hi Alistair,
> >
> > > On y2038 safe 32-bit systems the Linux kernel expects itimerval to
> > > use a 32-bit time_t, even though the other time_t's are 64-bit. To
> > > address this let's add a timeval_long
> > ^^^^^^^^^^^^^ - I'm not so seasoned glibc
> > developer, but I think that the _long
> > suffix is a bit misleading.
> >
> > Maybe it would be more readable to name it as struct
> > __timeval32 ? In that way one can see from the outset that
> > we operate on 32 bit values.
>
> It isn't explicitly 32-bit, it's just always a long which is why I
> went with long in the name instead.
>
> I'm happy to change the name, it doesn't really matter too much as
> it's only user internally.
>
> I'll wait to see what others think before changing it.
Yes, I also think that it would be best to wait for more input from the
community.
>
>
> Alistair
>
> >
> > Community feedback is welcome :-)
> >
> > > struct to be used internally.
> > > ---
> > > include/time.h | 29
> > > +++++++++++++++++++++++++++++ time/bits/types/struct_timeval.h |
> > > 8 ++++++++ 2 files changed, 37 insertions(+)
> > >
> > > diff --git a/include/time.h b/include/time.h
> > > index e5e8246eac..201342d1ca 100644
> > > --- a/include/time.h
> > > +++ b/include/time.h
> > > @@ -310,6 +310,35 @@ valid_timespec64_to_timeval (const struct
> > > __timespec64 ts64) return tv;
> > > }
> > >
> > > +/* Conversion functions for converting to/from __timeval_long
> > > +. If the seconds field of a __timeval_long would
> > > + overflow, they write { INT32_MAX, 999999 } to the output. */
> > > +static inline struct timeval
> > > +valid_timeval_long_to_timeval64 (const struct __timeval_long tv)
> > > +{
> > > + return (struct timeval) { tv.tv_sec, tv.tv_usec };
> > > +}
> > > +
> > > +static inline struct __timeval_long
> > > +valid_timeval64_to_timeval_long (const struct timeval tv64)
> > > +{
> > > + if (__glibc_unlikely (tv64.tv_sec > (time_t) 2147483647))
> > > + return (struct __timeval_long) { 2147483647, 999999};
> > > + return (struct __timeval_long) { tv64.tv_sec, tv64.tv_usec };
> > > +}
> > > +
> > > +static inline struct timespec
> > > +valid_timeval_long_to_timespec (const struct __timeval_long tv)
> > > +{
> > > + return (struct timespec) { tv.tv_sec, tv.tv_usec * 1000 };
> > > +}
> > > +
> > > +static inline struct __timeval_long
> > > +valid_timespec_to_timeval_long (const struct timespec ts)
> > > +{
> > > + return (struct __timeval_long) { (time_t) ts.tv_sec,
> > > ts.tv_nsec / 1000 }; +}
> > > +
> > > /* Check if a value is in the valid nanoseconds range. Return
> > > true if it is, false otherwise. */
> > > static inline bool
> > > diff --git a/time/bits/types/struct_timeval.h
> > > b/time/bits/types/struct_timeval.h index 70394ce886..73697689cc
> > > 100644 --- a/time/bits/types/struct_timeval.h
> > > +++ b/time/bits/types/struct_timeval.h
> > > @@ -10,4 +10,12 @@ struct timeval
> > > __time_t tv_sec; /* Seconds. */
> > > __suseconds_t tv_usec; /* Microseconds. */
> > > };
> > > +
> > > +/* A version of 'struct timeval' with `long` time_t
> > > + and suseconds_t. */
> > > +struct __timeval_long
> > > +{
> > > + long tv_sec; /* Seconds. */
> > > + long tv_usec; /* Microseconds. */
> > > +};
> > > #endif
> >
> > 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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* [RFC v6 04/23] linux: Use 32-bit time_t for itimerval
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (2 preceding siblings ...)
2020-01-12 10:33 ` [RFC v6 03/23] time: Add a timeval with a long tv_sec and tv_usec Alistair Francis
@ 2020-01-12 10:33 ` Alistair Francis
2020-01-14 10:58 ` Lukasz Majewski
2020-01-12 10:33 ` [RFC v6 05/23] linux: Use 32-bit time_t for rusage Alistair Francis
` (19 subsequent siblings)
23 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:33 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
The Linux kernel expects itimerval to use a 32-bit time_t, even on archs
with a 64-bit time_t (like RV32). To address this let's convert
itimerval to/from 32-bit and 64-bit to ensure the kernel always gets
a 32-bit time_t.
This means that all 32-bit architectures with a 64-bit time_t will be
able to use this generic implementation.
This code is bsaed on similar code in alpha, but adjusted to pass the
32-bit time_t to the kernel.
We can't directly call the __getitimer/__setitimer functions as they
expect a struct itimerval but we need to pass in a struct itimerval32.
---
.../linux/generic/wordsize-32/getitimer.c | 42 +++++++++++++++
.../linux/generic/wordsize-32/setitimer.c | 53 +++++++++++++++++++
.../linux/generic/wordsize-32/tv32-compat.h | 35 ++++++++++++
3 files changed, 130 insertions(+)
create mode 100644 sysdeps/unix/sysv/linux/generic/wordsize-32/getitimer.c
create mode 100644 sysdeps/unix/sysv/linux/generic/wordsize-32/setitimer.c
create mode 100644 sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h
diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/getitimer.c b/sysdeps/unix/sysv/linux/generic/wordsize-32/getitimer.c
new file mode 100644
index 0000000000..b279acbc2e
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/getitimer.c
@@ -0,0 +1,42 @@
+/* getitimer -- Get the state of an interval timer. Linux/RV32/tv32 version.
+ Copyright (C) 2020 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 <sys/time.h>
+#include <sysdep.h>
+#include <tv32-compat.h>
+
+int
+__getitimer (__itimer_which_t which, struct itimerval *curr_value)
+{
+#if __TIMESIZE == 64
+ struct itimerval32 curr_value_32;
+ if (INLINE_SYSCALL_CALL (getitimer, which, &curr_value_32) == -1)
+ return -1;
+
+ /* Write all fields of 'curr_value' regardless of overflow. */
+ curr_value->it_interval
+ = valid_timeval_long_to_timeval64 (curr_value_32.it_interval);
+ curr_value->it_value
+ = valid_timeval_long_to_timeval64 (curr_value_32.it_value);
+ return 0;
+#else
+ return INLINE_SYSCALL_CALL (getitimer, which, curr_value);
+#endif
+}
+
+weak_alias (__getitimer, getitimer)
diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/setitimer.c b/sysdeps/unix/sysv/linux/generic/wordsize-32/setitimer.c
new file mode 100644
index 0000000000..807683ccae
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/setitimer.c
@@ -0,0 +1,53 @@
+/* getitimer -- Get the state of an interval timer. Linux/RV32/tv32 version.
+ Copyright (C) 2020 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 <sys/time.h>
+#include <sysdep.h>
+#include <tv32-compat.h>
+
+int
+__setitimer (__itimer_which_t which,
+ const struct itimerval *restrict new_value,
+ struct itimerval *restrict old_value)
+{
+#if __TIMESIZE == 64
+ struct itimerval32 new_value_32;
+ new_value_32.it_interval
+ = valid_timeval64_to_timeval_long (new_value->it_interval);
+ new_value_32.it_value
+ = valid_timeval64_to_timeval_long (new_value->it_value);
+
+ if (old_value == NULL)
+ return INLINE_SYSCALL_CALL (setitimer, which, &new_value_32, NULL);
+
+ struct itimerval32 old_value_32;
+ if (INLINE_SYSCALL_CALL (setitimer, which, &new_value_32, &old_value_32) == -1)
+ return -1;
+
+ /* Write all fields of 'old_value' regardless of overflow. */
+ old_value->it_interval
+ = valid_timeval_long_to_timeval64 (old_value_32.it_interval);
+ old_value->it_value
+ = valid_timeval_long_to_timeval64 (old_value_32.it_value);
+ return 0;
+#else
+ return INLINE_SYSCALL_CALL (setitimer, which, new_value, old_value);
+#endif
+}
+
+weak_alias (__setitimer, setitimer)
diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h b/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h
new file mode 100644
index 0000000000..aa960a6632
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h
@@ -0,0 +1,35 @@
+/* Compatibility definitions for `struct timeval' with 32-bit time_t.
+ Copyright (C) 2020 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 _TV32_COMPAT_H
+#define _TV32_COMPAT_H 1
+
+#include <features.h>
+
+#include <bits/types.h>
+#include <bits/types/time_t.h>
+#include <bits/types/struct_timeval.h>
+
+/* Structures containing 'struct timeval' with 32-bit time_t. */
+struct itimerval32
+{
+ struct __timeval_long it_interval;
+ struct __timeval_long it_value;
+};
+
+#endif /* tv32-compat.h */
--
2.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* Re: [RFC v6 04/23] linux: Use 32-bit time_t for itimerval
2020-01-12 10:33 ` [RFC v6 04/23] linux: Use 32-bit time_t for itimerval Alistair Francis
@ 2020-01-14 10:58 ` Lukasz Majewski
2020-01-15 23:39 ` Alistair Francis
0 siblings, 1 reply; 138+ messages in thread
From: Lukasz Majewski @ 2020-01-14 10:58 UTC (permalink / raw)
To: Alistair Francis
Cc: libc-alpha, arnd, adhemerval.zanella, fweimer, joseph,
palmerdabbelt, macro, zongbox, alistair23
[-- Attachment #1: Type: text/plain, Size: 7944 bytes --]
Hi Alistair,
> The Linux kernel expects itimerval to use a 32-bit time_t, even on
> archs with a 64-bit time_t (like RV32). To address this let's convert
> itimerval to/from 32-bit and 64-bit to ensure the kernel always gets
> a 32-bit time_t.
>
> This means that all 32-bit architectures with a 64-bit time_t will be
> able to use this generic implementation.
>
> This code is bsaed on similar code in alpha, but adjusted to pass the
> 32-bit time_t to the kernel.
>
> We can't directly call the __getitimer/__setitimer functions as they
> expect a struct itimerval but we need to pass in a struct itimerval32.
> ---
> .../linux/generic/wordsize-32/getitimer.c | 42 +++++++++++++++
> .../linux/generic/wordsize-32/setitimer.c | 53
> +++++++++++++++++++ .../linux/generic/wordsize-32/tv32-compat.h |
> 35 ++++++++++++ 3 files changed, 130 insertions(+)
> create mode 100644
> sysdeps/unix/sysv/linux/generic/wordsize-32/getitimer.c create mode
> 100644 sysdeps/unix/sysv/linux/generic/wordsize-32/setitimer.c create
> mode 100644 sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h
>
> diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/getitimer.c
> b/sysdeps/unix/sysv/linux/generic/wordsize-32/getitimer.c new file
> mode 100644 index 0000000000..b279acbc2e
> --- /dev/null
> +++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/getitimer.c
> @@ -0,0 +1,42 @@
> +/* getitimer -- Get the state of an interval timer. Linux/RV32/tv32
> version.
> + Copyright (C) 2020 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 <sys/time.h>
> +#include <sysdep.h>
> +#include <tv32-compat.h>
> +
> +int
> +__getitimer (__itimer_which_t which, struct itimerval *curr_value)
> +{
> +#if __TIMESIZE == 64
> + struct itimerval32 curr_value_32;
> + if (INLINE_SYSCALL_CALL (getitimer, which, &curr_value_32) == -1)
> + return -1;
> +
> + /* Write all fields of 'curr_value' regardless of overflow. */
> + curr_value->it_interval
> + = valid_timeval_long_to_timeval64 (curr_value_32.it_interval);
> + curr_value->it_value
> + = valid_timeval_long_to_timeval64 (curr_value_32.it_value);
> + return 0;
> +#else
> + return INLINE_SYSCALL_CALL (getitimer, which, curr_value);
> +#endif
> +}
> +
> +weak_alias (__getitimer, getitimer)
> diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/setitimer.c
> b/sysdeps/unix/sysv/linux/generic/wordsize-32/setitimer.c new file
> mode 100644 index 0000000000..807683ccae
> --- /dev/null
> +++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/setitimer.c
> @@ -0,0 +1,53 @@
> +/* getitimer -- Get the state of an interval timer. Linux/RV32/tv32
> version.
Please update the header info. I suppose you refer to setitimer here.
> + Copyright (C) 2020 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 <sys/time.h>
> +#include <sysdep.h>
> +#include <tv32-compat.h>
> +
> +int
> +__setitimer (__itimer_which_t which,
> + const struct itimerval *restrict new_value,
> + struct itimerval *restrict old_value)
> +{
> +#if __TIMESIZE == 64
I think that Y2038 safe systems with __WORDSIZE == 32 && __TIMESIZE ==
32 (for now?) also could reuse this work.
To allow it this syscall wrapper shall be converted (written) in the
same way as e.g:
./sysdeps/unix/sysv/linux/clock_settime.c
(the same issue is with getitimer).
Then only redirection when __USE_TIME_BITS64 is set are needed to use
__setitimer64/__getitimer64 on Y2038 safe systems.
> + struct itimerval32 new_value_32;
> + new_value_32.it_interval
> + = valid_timeval64_to_timeval_long (new_value->it_interval);
> + new_value_32.it_value
> + = valid_timeval64_to_timeval_long (new_value->it_value);
> +
> + if (old_value == NULL)
> + return INLINE_SYSCALL_CALL (setitimer, which, &new_value_32,
> NULL); +
> + struct itimerval32 old_value_32;
> + if (INLINE_SYSCALL_CALL (setitimer, which, &new_value_32,
> &old_value_32) == -1)
> + return -1;
> +
> + /* Write all fields of 'old_value' regardless of overflow. */
> + old_value->it_interval
> + = valid_timeval_long_to_timeval64 (old_value_32.it_interval);
> + old_value->it_value
> + = valid_timeval_long_to_timeval64 (old_value_32.it_value);
> + return 0;
> +#else
> + return INLINE_SYSCALL_CALL (setitimer, which, new_value,
> old_value); +#endif
> +}
> +
> +weak_alias (__setitimer, setitimer)
> diff --git
> a/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h
> b/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h new file
> mode 100644 index 0000000000..aa960a6632 --- /dev/null
> +++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h
> @@ -0,0 +1,35 @@
> +/* Compatibility definitions for `struct timeval' with 32-bit time_t.
> + Copyright (C) 2020 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 _TV32_COMPAT_H
> +#define _TV32_COMPAT_H 1
> +
> +#include <features.h>
> +
> +#include <bits/types.h>
> +#include <bits/types/time_t.h>
> +#include <bits/types/struct_timeval.h>
> +
> +/* Structures containing 'struct timeval' with 32-bit time_t. */
> +struct itimerval32
> +{
> + struct __timeval_long it_interval;
> + struct __timeval_long it_value;
> +};
> +
> +#endif /* tv32-compat.h */
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: 484 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 04/23] linux: Use 32-bit time_t for itimerval
2020-01-14 10:58 ` Lukasz Majewski
@ 2020-01-15 23:39 ` Alistair Francis
2020-01-16 1:21 ` Joseph Myers
0 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-01-15 23:39 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Joseph Myers, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Tue, Jan 14, 2020 at 8:58 PM Lukasz Majewski <lukma@denx.de> wrote:
>
> Hi Alistair,
>
> > The Linux kernel expects itimerval to use a 32-bit time_t, even on
> > archs with a 64-bit time_t (like RV32). To address this let's convert
> > itimerval to/from 32-bit and 64-bit to ensure the kernel always gets
> > a 32-bit time_t.
> >
> > This means that all 32-bit architectures with a 64-bit time_t will be
> > able to use this generic implementation.
> >
> > This code is bsaed on similar code in alpha, but adjusted to pass the
> > 32-bit time_t to the kernel.
> >
> > We can't directly call the __getitimer/__setitimer functions as they
> > expect a struct itimerval but we need to pass in a struct itimerval32.
> > ---
> > .../linux/generic/wordsize-32/getitimer.c | 42 +++++++++++++++
> > .../linux/generic/wordsize-32/setitimer.c | 53
> > +++++++++++++++++++ .../linux/generic/wordsize-32/tv32-compat.h |
> > 35 ++++++++++++ 3 files changed, 130 insertions(+)
> > create mode 100644
> > sysdeps/unix/sysv/linux/generic/wordsize-32/getitimer.c create mode
> > 100644 sysdeps/unix/sysv/linux/generic/wordsize-32/setitimer.c create
> > mode 100644 sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h
> >
> > diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/getitimer.c
> > b/sysdeps/unix/sysv/linux/generic/wordsize-32/getitimer.c new file
> > mode 100644 index 0000000000..b279acbc2e
> > --- /dev/null
> > +++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/getitimer.c
> > @@ -0,0 +1,42 @@
> > +/* getitimer -- Get the state of an interval timer. Linux/RV32/tv32
> > version.
> > + Copyright (C) 2020 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 <sys/time.h>
> > +#include <sysdep.h>
> > +#include <tv32-compat.h>
> > +
> > +int
> > +__getitimer (__itimer_which_t which, struct itimerval *curr_value)
> > +{
> > +#if __TIMESIZE == 64
> > + struct itimerval32 curr_value_32;
> > + if (INLINE_SYSCALL_CALL (getitimer, which, &curr_value_32) == -1)
> > + return -1;
> > +
> > + /* Write all fields of 'curr_value' regardless of overflow. */
> > + curr_value->it_interval
> > + = valid_timeval_long_to_timeval64 (curr_value_32.it_interval);
> > + curr_value->it_value
> > + = valid_timeval_long_to_timeval64 (curr_value_32.it_value);
> > + return 0;
> > +#else
> > + return INLINE_SYSCALL_CALL (getitimer, which, curr_value);
> > +#endif
> > +}
> > +
> > +weak_alias (__getitimer, getitimer)
> > diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/setitimer.c
> > b/sysdeps/unix/sysv/linux/generic/wordsize-32/setitimer.c new file
> > mode 100644 index 0000000000..807683ccae
> > --- /dev/null
> > +++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/setitimer.c
> > @@ -0,0 +1,53 @@
> > +/* getitimer -- Get the state of an interval timer. Linux/RV32/tv32
> > version.
>
> Please update the header info. I suppose you refer to setitimer here.
Fixed!
>
> > + Copyright (C) 2020 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 <sys/time.h>
> > +#include <sysdep.h>
> > +#include <tv32-compat.h>
> > +
> > +int
> > +__setitimer (__itimer_which_t which,
> > + const struct itimerval *restrict new_value,
> > + struct itimerval *restrict old_value)
> > +{
> > +#if __TIMESIZE == 64
>
> I think that Y2038 safe systems with __WORDSIZE == 32 && __TIMESIZE ==
> 32 (for now?) also could reuse this work.
>
> To allow it this syscall wrapper shall be converted (written) in the
> same way as e.g:
>
> ./sysdeps/unix/sysv/linux/clock_settime.c
>
> (the same issue is with getitimer).
>
> Then only redirection when __USE_TIME_BITS64 is set are needed to use
> __setitimer64/__getitimer64 on Y2038 safe systems.
I'm not sure what you mean here.
There is no setitimer64/getitimer64 syscall so we need to make sure we
pass a 32-bit time_t here. If __TIMESIZE == 32 then we don't need any
changes and can just directly make the syscall (as we do in this
patch). The conversion is only required if __TIMESIZE == 64 as we need
to convert to/from a 32-bit time_t.
Alistair
>
> > + struct itimerval32 new_value_32;
> > + new_value_32.it_interval
> > + = valid_timeval64_to_timeval_long (new_value->it_interval);
> > + new_value_32.it_value
> > + = valid_timeval64_to_timeval_long (new_value->it_value);
> > +
> > + if (old_value == NULL)
> > + return INLINE_SYSCALL_CALL (setitimer, which, &new_value_32,
> > NULL); +
> > + struct itimerval32 old_value_32;
> > + if (INLINE_SYSCALL_CALL (setitimer, which, &new_value_32,
> > &old_value_32) == -1)
> > + return -1;
> > +
> > + /* Write all fields of 'old_value' regardless of overflow. */
> > + old_value->it_interval
> > + = valid_timeval_long_to_timeval64 (old_value_32.it_interval);
> > + old_value->it_value
> > + = valid_timeval_long_to_timeval64 (old_value_32.it_value);
> > + return 0;
> > +#else
> > + return INLINE_SYSCALL_CALL (setitimer, which, new_value,
> > old_value); +#endif
> > +}
> > +
> > +weak_alias (__setitimer, setitimer)
> > diff --git
> > a/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h
> > b/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h new file
> > mode 100644 index 0000000000..aa960a6632 --- /dev/null
> > +++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h
> > @@ -0,0 +1,35 @@
> > +/* Compatibility definitions for `struct timeval' with 32-bit time_t.
> > + Copyright (C) 2020 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 _TV32_COMPAT_H
> > +#define _TV32_COMPAT_H 1
> > +
> > +#include <features.h>
> > +
> > +#include <bits/types.h>
> > +#include <bits/types/time_t.h>
> > +#include <bits/types/struct_timeval.h>
> > +
> > +/* Structures containing 'struct timeval' with 32-bit time_t. */
> > +struct itimerval32
> > +{
> > + struct __timeval_long it_interval;
> > + struct __timeval_long it_value;
> > +};
> > +
> > +#endif /* tv32-compat.h */
>
>
> 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
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 04/23] linux: Use 32-bit time_t for itimerval
2020-01-15 23:39 ` Alistair Francis
@ 2020-01-16 1:21 ` Joseph Myers
2020-01-16 1:33 ` Alistair Francis
0 siblings, 1 reply; 138+ messages in thread
From: Joseph Myers @ 2020-01-16 1:21 UTC (permalink / raw)
To: Alistair Francis
Cc: Lukasz Majewski, Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Thu, 16 Jan 2020, Alistair Francis wrote:
> > To allow it this syscall wrapper shall be converted (written) in the
> > same way as e.g:
> >
> > ./sysdeps/unix/sysv/linux/clock_settime.c
> >
> > (the same issue is with getitimer).
> >
> > Then only redirection when __USE_TIME_BITS64 is set are needed to use
> > __setitimer64/__getitimer64 on Y2038 safe systems.
>
> I'm not sure what you mean here.
>
> There is no setitimer64/getitimer64 syscall so we need to make sure we
> pass a 32-bit time_t here. If __TIMESIZE == 32 then we don't need any
> changes and can just directly make the syscall (as we do in this
> patch). The conversion is only required if __TIMESIZE == 64 as we need
> to convert to/from a 32-bit time_t.
This is a point about the general structure and goals of the Y2038 work.
We want to end up at a point where, on systems where time_t is currently
32-bit, you can build with -D_TIME_BITS=64 and get 64-bit time_t instead.
That means that all time-related functions, including getitimer and
setitimer, will, on such systems, need to have two implementations in
glibc, one using 64-bit times and one using 32-bit times.
The implementation structure generally being used is that the main
implementation has an interface using 64-bit times (even if it ends up
using syscalls with 32-bit times) and the one using 32-bit times is a thin
wrapper around it (if time_t is already 64-bit, the second implementation
does not exist and some macros ensure the first implementation keeps its
existing name). Once all functions have been moved to that structure, we
can set things up so that all those 64-bit functions are exported from
glibc and add _TIME_BITS support in the headers.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 04/23] linux: Use 32-bit time_t for itimerval
2020-01-16 1:21 ` Joseph Myers
@ 2020-01-16 1:33 ` Alistair Francis
2020-01-16 13:34 ` Lukasz Majewski
2020-01-16 16:19 ` Joseph Myers
0 siblings, 2 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-16 1:33 UTC (permalink / raw)
To: Joseph Myers
Cc: Lukasz Majewski, Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Thu, Jan 16, 2020 at 11:21 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 16 Jan 2020, Alistair Francis wrote:
>
> > > To allow it this syscall wrapper shall be converted (written) in the
> > > same way as e.g:
> > >
> > > ./sysdeps/unix/sysv/linux/clock_settime.c
> > >
> > > (the same issue is with getitimer).
> > >
> > > Then only redirection when __USE_TIME_BITS64 is set are needed to use
> > > __setitimer64/__getitimer64 on Y2038 safe systems.
> >
> > I'm not sure what you mean here.
> >
> > There is no setitimer64/getitimer64 syscall so we need to make sure we
> > pass a 32-bit time_t here. If __TIMESIZE == 32 then we don't need any
> > changes and can just directly make the syscall (as we do in this
> > patch). The conversion is only required if __TIMESIZE == 64 as we need
> > to convert to/from a 32-bit time_t.
>
> This is a point about the general structure and goals of the Y2038 work.
>
> We want to end up at a point where, on systems where time_t is currently
> 32-bit, you can build with -D_TIME_BITS=64 and get 64-bit time_t instead.
> That means that all time-related functions, including getitimer and
> setitimer, will, on such systems, need to have two implementations in
> glibc, one using 64-bit times and one using 32-bit times.
I'm still confused. If we build with -D_TIME_BITS=64 does that then
mean that __TIMESIZE == 64 ?
In which case the user exposed time_t is 64-bit and these calls will
take a 64-bit time_t and convert it to/from a 32-bit time_t to pass to
the kernel. The user will only ever use/see a 64-bit time_t.
>
> The implementation structure generally being used is that the main
> implementation has an interface using 64-bit times (even if it ends up
> using syscalls with 32-bit times) and the one using 32-bit times is a thin
Isn't that what is happening here when __TIMESIZE == 64 ?
> wrapper around it (if time_t is already 64-bit, the second implementation
> does not exist and some macros ensure the first implementation keeps its
> existing name). Once all functions have been moved to that structure, we
> can set things up so that all those 64-bit functions are exported from
> glibc and add _TIME_BITS support in the headers.
Ah, do you mean that glibc should expose a 64-bit time_t version if
__TIMESIZE == 32? So even __TIMESIZE == 32 systems can call a 64-bit
time_t version (even if the syscall ends up being 32-bit).
Alistair
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 04/23] linux: Use 32-bit time_t for itimerval
2020-01-16 1:33 ` Alistair Francis
@ 2020-01-16 13:34 ` Lukasz Majewski
2020-01-17 6:39 ` Alistair Francis
2020-01-16 16:19 ` Joseph Myers
1 sibling, 1 reply; 138+ messages in thread
From: Lukasz Majewski @ 2020-01-16 13:34 UTC (permalink / raw)
To: Alistair Francis, Joseph Myers
Cc: Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
[-- Attachment #1: Type: text/plain, Size: 4220 bytes --]
Hi Alistair, Joseph
> On Thu, Jan 16, 2020 at 11:21 AM Joseph Myers
> <joseph@codesourcery.com> wrote:
> >
> > On Thu, 16 Jan 2020, Alistair Francis wrote:
> >
> > > > To allow it this syscall wrapper shall be converted (written)
> > > > in the same way as e.g:
> > > >
> > > > ./sysdeps/unix/sysv/linux/clock_settime.c
> > > >
> > > > (the same issue is with getitimer).
> > > >
> > > > Then only redirection when __USE_TIME_BITS64 is set are needed
> > > > to use __setitimer64/__getitimer64 on Y2038 safe systems.
> > >
> > > I'm not sure what you mean here.
> > >
> > > There is no setitimer64/getitimer64 syscall so we need to make
> > > sure we pass a 32-bit time_t here. If __TIMESIZE == 32 then we
> > > don't need any changes and can just directly make the syscall (as
> > > we do in this patch). The conversion is only required if
> > > __TIMESIZE == 64 as we need to convert to/from a 32-bit time_t.
> >
> > This is a point about the general structure and goals of the Y2038
> > work.
> >
> > We want to end up at a point where, on systems where time_t is
> > currently 32-bit, you can build with -D_TIME_BITS=64 and get 64-bit
> > time_t instead. That means that all time-related functions,
> > including getitimer and setitimer, will, on such systems, need to
> > have two implementations in glibc, one using 64-bit times and one
> > using 32-bit times.
>
> I'm still confused. If we build with -D_TIME_BITS=64 does that then
> mean that __TIMESIZE == 64 ?
>
> In which case the user exposed time_t is 64-bit and these calls will
> take a 64-bit time_t and convert it to/from a 32-bit time_t to pass to
> the kernel. The user will only ever use/see a 64-bit time_t.
>
> >
> > The implementation structure generally being used is that the main
> > implementation has an interface using 64-bit times (even if it ends
> > up using syscalls with 32-bit times) and the one using 32-bit times
> > is a thin
>
> Isn't that what is happening here when __TIMESIZE == 64 ?
>
> > wrapper around it (if time_t is already 64-bit, the second
> > implementation does not exist and some macros ensure the first
> > implementation keeps its existing name). Once all functions have
> > been moved to that structure, we can set things up so that all
> > those 64-bit functions are exported from glibc and add _TIME_BITS
> > support in the headers.
>
> Ah, do you mean that glibc should expose a 64-bit time_t version if
> __TIMESIZE == 32?
Yes, exactly.
Currently 32 bit ARM (__WORDSIZE == 32 && __TIMESIZE == 32) use 32 bit
time_t. However, after compiling the source code with -D_TIME_BITS=64
the time_t will become 64 bit.
Please find example setup for tests_y2038:
https://github.com/lmajewski/y2038-tests/blob/master/Makefile#L25
(Two binaries are build from the same sources - one is Y2038 safe and
other is not).
The notable difference between the new RV32 port and existing ARM32 is
that for new ports (i.e. RV32) the __TIMESIZE = 64 is set from the
outset.
For the latter (ARM32) the __TIMESIZE = 32 is kept and IIRC we will
NOT update it to __TIMESIZE = 64 anytime soon. Instead, in exported
headers _TIME_BITS=64 will be set by default (approach similar to the
one for _FILE_OFFSET_BITS=64).
Joseph, am I right?
> So even __TIMESIZE == 32 systems can call a 64-bit
> time_t version (even if the syscall ends up being 32-bit).
+1
Please find example conversion code for timespec_get conversion:
https://patchwork.ozlabs.org/patch/1224222/
it internally uses __clock_gettime64, which uses 64 bit time no matter
on which architecture it runs (even with __TIMESIZE==32).
Please also refer to the branch, which moves 32 bit ports closer to
being Y2038 safe:
https://github.com/lmajewski/y2038_glibc/commits/glibc_timespec_get-conversion-v1
>
> Alistair
>
> >
> > --
> > Joseph S. Myers
> > joseph@codesourcery.com
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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 04/23] linux: Use 32-bit time_t for itimerval
2020-01-16 13:34 ` Lukasz Majewski
@ 2020-01-17 6:39 ` Alistair Francis
2020-01-17 11:14 ` Lukasz Majewski
0 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-01-17 6:39 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Joseph Myers, Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Thu, Jan 16, 2020 at 11:34 PM Lukasz Majewski <lukma@denx.de> wrote:
>
> Hi Alistair, Joseph
>
> > On Thu, Jan 16, 2020 at 11:21 AM Joseph Myers
> > <joseph@codesourcery.com> wrote:
> > >
> > > On Thu, 16 Jan 2020, Alistair Francis wrote:
> > >
> > > > > To allow it this syscall wrapper shall be converted (written)
> > > > > in the same way as e.g:
> > > > >
> > > > > ./sysdeps/unix/sysv/linux/clock_settime.c
> > > > >
> > > > > (the same issue is with getitimer).
> > > > >
> > > > > Then only redirection when __USE_TIME_BITS64 is set are needed
> > > > > to use __setitimer64/__getitimer64 on Y2038 safe systems.
> > > >
> > > > I'm not sure what you mean here.
> > > >
> > > > There is no setitimer64/getitimer64 syscall so we need to make
> > > > sure we pass a 32-bit time_t here. If __TIMESIZE == 32 then we
> > > > don't need any changes and can just directly make the syscall (as
> > > > we do in this patch). The conversion is only required if
> > > > __TIMESIZE == 64 as we need to convert to/from a 32-bit time_t.
> > >
> > > This is a point about the general structure and goals of the Y2038
> > > work.
> > >
> > > We want to end up at a point where, on systems where time_t is
> > > currently 32-bit, you can build with -D_TIME_BITS=64 and get 64-bit
> > > time_t instead. That means that all time-related functions,
> > > including getitimer and setitimer, will, on such systems, need to
> > > have two implementations in glibc, one using 64-bit times and one
> > > using 32-bit times.
> >
> > I'm still confused. If we build with -D_TIME_BITS=64 does that then
> > mean that __TIMESIZE == 64 ?
> >
> > In which case the user exposed time_t is 64-bit and these calls will
> > take a 64-bit time_t and convert it to/from a 32-bit time_t to pass to
> > the kernel. The user will only ever use/see a 64-bit time_t.
> >
> > >
> > > The implementation structure generally being used is that the main
> > > implementation has an interface using 64-bit times (even if it ends
> > > up using syscalls with 32-bit times) and the one using 32-bit times
> > > is a thin
> >
> > Isn't that what is happening here when __TIMESIZE == 64 ?
> >
> > > wrapper around it (if time_t is already 64-bit, the second
> > > implementation does not exist and some macros ensure the first
> > > implementation keeps its existing name). Once all functions have
> > > been moved to that structure, we can set things up so that all
> > > those 64-bit functions are exported from glibc and add _TIME_BITS
> > > support in the headers.
> >
> > Ah, do you mean that glibc should expose a 64-bit time_t version if
> > __TIMESIZE == 32?
>
> Yes, exactly.
>
> Currently 32 bit ARM (__WORDSIZE == 32 && __TIMESIZE == 32) use 32 bit
> time_t. However, after compiling the source code with -D_TIME_BITS=64
> the time_t will become 64 bit.
>
> Please find example setup for tests_y2038:
> https://github.com/lmajewski/y2038-tests/blob/master/Makefile#L25
> (Two binaries are build from the same sources - one is Y2038 safe and
> other is not).
>
> The notable difference between the new RV32 port and existing ARM32 is
> that for new ports (i.e. RV32) the __TIMESIZE = 64 is set from the
> outset.
> For the latter (ARM32) the __TIMESIZE = 32 is kept and IIRC we will
> NOT update it to __TIMESIZE = 64 anytime soon. Instead, in exported
> headers _TIME_BITS=64 will be set by default (approach similar to the
> one for _FILE_OFFSET_BITS=64).
Doesn't that mean that I can fix this all by just using if _TIME_BITS
== 64 instead of __TIMESIZE?
>
> Joseph, am I right?
>
> > So even __TIMESIZE == 32 systems can call a 64-bit
> > time_t version (even if the syscall ends up being 32-bit).
>
> +1
Even if time_t is 64-bit you can't pass a value larger then 32-bits to
these functions as they get converted back to a 32-bit value for the
kernel syscall.
>
> Please find example conversion code for timespec_get conversion:
> https://patchwork.ozlabs.org/patch/1224222/
>
> it internally uses __clock_gettime64, which uses 64 bit time no matter
> on which architecture it runs (even with __TIMESIZE==32).
In this case though the syscall is always 32-bit, so I'm not sure if
there is a huge advantage here.
I don't see a point of converting this function to take a 64-bit value
if time_t is 32-bit as that doesn't give you anything. It does seem
worth changing the #if to check _TIME_BITS == 64 instead of __TIMESIZE
though.
Alistair
>
> Please also refer to the branch, which moves 32 bit ports closer to
> being Y2038 safe:
>
> https://github.com/lmajewski/y2038_glibc/commits/glibc_timespec_get-conversion-v1
>
> >
> > Alistair
> >
> > >
> > > --
> > > Joseph S. Myers
> > > joseph@codesourcery.com
>
>
>
>
> 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
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 04/23] linux: Use 32-bit time_t for itimerval
2020-01-17 6:39 ` Alistair Francis
@ 2020-01-17 11:14 ` Lukasz Majewski
2020-01-17 12:03 ` Alistair Francis
0 siblings, 1 reply; 138+ messages in thread
From: Lukasz Majewski @ 2020-01-17 11:14 UTC (permalink / raw)
To: Alistair Francis
Cc: Joseph Myers, Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
[-- Attachment #1: Type: text/plain, Size: 8118 bytes --]
Hi Alistair,
> On Thu, Jan 16, 2020 at 11:34 PM Lukasz Majewski <lukma@denx.de>
> wrote:
> >
> > Hi Alistair, Joseph
> >
> > > On Thu, Jan 16, 2020 at 11:21 AM Joseph Myers
> > > <joseph@codesourcery.com> wrote:
> > > >
> > > > On Thu, 16 Jan 2020, Alistair Francis wrote:
> > > >
> > > > > > To allow it this syscall wrapper shall be converted
> > > > > > (written) in the same way as e.g:
> > > > > >
> > > > > > ./sysdeps/unix/sysv/linux/clock_settime.c
> > > > > >
> > > > > > (the same issue is with getitimer).
> > > > > >
> > > > > > Then only redirection when __USE_TIME_BITS64 is set are
> > > > > > needed to use __setitimer64/__getitimer64 on Y2038 safe
> > > > > > systems.
> > > > >
> > > > > I'm not sure what you mean here.
> > > > >
> > > > > There is no setitimer64/getitimer64 syscall so we need to make
> > > > > sure we pass a 32-bit time_t here. If __TIMESIZE == 32 then we
> > > > > don't need any changes and can just directly make the syscall
> > > > > (as we do in this patch). The conversion is only required if
> > > > > __TIMESIZE == 64 as we need to convert to/from a 32-bit
> > > > > time_t.
> > > >
> > > > This is a point about the general structure and goals of the
> > > > Y2038 work.
> > > >
> > > > We want to end up at a point where, on systems where time_t is
> > > > currently 32-bit, you can build with -D_TIME_BITS=64 and get
> > > > 64-bit time_t instead. That means that all time-related
> > > > functions, including getitimer and setitimer, will, on such
> > > > systems, need to have two implementations in glibc, one using
> > > > 64-bit times and one using 32-bit times.
> > >
> > > I'm still confused. If we build with -D_TIME_BITS=64 does that
> > > then mean that __TIMESIZE == 64 ?
> > >
> > > In which case the user exposed time_t is 64-bit and these calls
> > > will take a 64-bit time_t and convert it to/from a 32-bit time_t
> > > to pass to the kernel. The user will only ever use/see a 64-bit
> > > time_t.
> > > >
> > > > The implementation structure generally being used is that the
> > > > main implementation has an interface using 64-bit times (even
> > > > if it ends up using syscalls with 32-bit times) and the one
> > > > using 32-bit times is a thin
> > >
> > > Isn't that what is happening here when __TIMESIZE == 64 ?
> > >
> > > > wrapper around it (if time_t is already 64-bit, the second
> > > > implementation does not exist and some macros ensure the first
> > > > implementation keeps its existing name). Once all functions
> > > > have been moved to that structure, we can set things up so that
> > > > all those 64-bit functions are exported from glibc and add
> > > > _TIME_BITS support in the headers.
> > >
> > > Ah, do you mean that glibc should expose a 64-bit time_t version
> > > if __TIMESIZE == 32?
> >
> > Yes, exactly.
> >
> > Currently 32 bit ARM (__WORDSIZE == 32 && __TIMESIZE == 32) use 32
> > bit time_t. However, after compiling the source code with
> > -D_TIME_BITS=64 the time_t will become 64 bit.
> >
> > Please find example setup for tests_y2038:
> > https://github.com/lmajewski/y2038-tests/blob/master/Makefile#L25
> > (Two binaries are build from the same sources - one is Y2038 safe
> > and other is not).
> >
> > The notable difference between the new RV32 port and existing ARM32
> > is that for new ports (i.e. RV32) the __TIMESIZE = 64 is set from
> > the outset.
> > For the latter (ARM32) the __TIMESIZE = 32 is kept and IIRC we will
> > NOT update it to __TIMESIZE = 64 anytime soon. Instead, in exported
> > headers _TIME_BITS=64 will be set by default (approach similar to
> > the one for _FILE_OFFSET_BITS=64).
>
> Doesn't that mean that I can fix this all by just using if _TIME_BITS
> == 64 instead of __TIMESIZE?
Unfortunately, not. The _TIME_BITS define affects _exported_ glibc
headers. It sets __USE_TIME_BITS64, which shall NOT be used in glibc
internals:
https://github.com/lmajewski/y2038_glibc/commit/319c24507974fecdffe5182d310289b2a4cb9122#diff-a5ab6c74681eaf0569ed54f6bf0d7978R391
Instead, the glibc shall be prepared for handling those syscalls
correctly in both cases - when _TIME_BITS == 64 (Y2038 safe) is defined
or not during the compilation.
>
> >
> > Joseph, am I right?
> >
> > > So even __TIMESIZE == 32 systems can call a 64-bit
> > > time_t version (even if the syscall ends up being 32-bit).
> >
> > +1
>
> Even if time_t is 64-bit you can't pass a value larger then 32-bits to
> these functions as they get converted back to a 32-bit value for the
> kernel syscall.
The problem is with consistency:
1. Internally glibc is going to replace time_t (which may be 32 bit)
with __time64_t (as it is done indirectly with introduction of struct
__timespec64, etc). In that way glibc will be itself Y2038 safe no
matter of __TIMESIZE value (32, 64 bit).
2. The functions with 64 suffix (i.e. __getitimer64, __settime64)
e.g.:
int
__getitimer64 (__itimer_which_t which, struct __itimerval64 *curr_value)
Will use struct __itimerval64, which will always support 64 bit time
(the same situation as with struct __itimerspec64).
Afterwards, I will define redirection for it in the exported headers -
like for example here (for timerspec_get):
https://github.com/lmajewski/y2038_glibc/commit/9844cb7beb854e21bbdc595398627777b6155c27#diff-07934c1fe09f0e6357413e138856c786R320
This redirection will force usage of __gettimer64 on ARM32 bit
(__TIMESIZE==32 && __WORDSIZE==32) when -D_TIME_BITS=64 is set during
compilation.
(I'm now finishing patches to introduce struct __timeval64 to glibc)
>
> >
> > Please find example conversion code for timespec_get conversion:
> > https://patchwork.ozlabs.org/patch/1224222/
> >
> > it internally uses __clock_gettime64, which uses 64 bit time no
> > matter on which architecture it runs (even with __TIMESIZE==32).
>
> In this case though the syscall is always 32-bit, so I'm not sure if
> there is a huge advantage here.
The advantage is that the consistency of function conversion will be
preserved. The __gettimer64 function will be used, even though we will
use 32 bit syscalls and when kernel (maybe?) introduce 64 bit syscalls
we will be ready.
>
> I don't see a point of converting this function to take a 64-bit value
> if time_t is 32-bit as that doesn't give you anything.
time_t may be 32 bit or 64 on the Y2038 safe systems. It depends on
adding -D_TIME_BITS=64 during compilation.
> It does seem
> worth changing the #if to check _TIME_BITS == 64 instead of __TIMESIZE
> though.
As I've stated above - the _TIME_BITS (and __USE_TIME_BITS64) are
supposed to be "visible" in the glibc exported headers.
The __USE_TIME_BITS64 flag enables redirection for the syscalls:
https://github.com/lmajewski/y2038_glibc/commit/319c24507974fecdffe5182d310289b2a4cb9122#diff-8bdb75c23cf534160b06f2dc2183e971R67
On the glibc side one shall have time functions converted to:
https://github.com/lmajewski/y2038_glibc/commit/6367f6e061c5184b39cf7fff07ffcf8b569d765e#diff-a8bb3b17dcb4b2b40deba97323563301R33
>
> Alistair
>
> >
> > Please also refer to the branch, which moves 32 bit ports closer to
> > being Y2038 safe:
> >
> > https://github.com/lmajewski/y2038_glibc/commits/glibc_timespec_get-conversion-v1
> >
> > >
> > > Alistair
> > >
> > > >
> > > > --
> > > > Joseph S. Myers
> > > > joseph@codesourcery.com
> >
> >
> >
> >
> > 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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 04/23] linux: Use 32-bit time_t for itimerval
2020-01-17 11:14 ` Lukasz Majewski
@ 2020-01-17 12:03 ` Alistair Francis
2020-01-17 12:19 ` Lukasz Majewski
2020-01-17 14:14 ` Joseph Myers
0 siblings, 2 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-17 12:03 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Joseph Myers, Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Fri, Jan 17, 2020 at 9:14 PM Lukasz Majewski <lukma@denx.de> wrote:
>
> Hi Alistair,
>
> > On Thu, Jan 16, 2020 at 11:34 PM Lukasz Majewski <lukma@denx.de>
> > wrote:
> > >
> > > Hi Alistair, Joseph
> > >
> > > > On Thu, Jan 16, 2020 at 11:21 AM Joseph Myers
> > > > <joseph@codesourcery.com> wrote:
> > > > >
> > > > > On Thu, 16 Jan 2020, Alistair Francis wrote:
> > > > >
> > > > > > > To allow it this syscall wrapper shall be converted
> > > > > > > (written) in the same way as e.g:
> > > > > > >
> > > > > > > ./sysdeps/unix/sysv/linux/clock_settime.c
> > > > > > >
> > > > > > > (the same issue is with getitimer).
> > > > > > >
> > > > > > > Then only redirection when __USE_TIME_BITS64 is set are
> > > > > > > needed to use __setitimer64/__getitimer64 on Y2038 safe
> > > > > > > systems.
> > > > > >
> > > > > > I'm not sure what you mean here.
> > > > > >
> > > > > > There is no setitimer64/getitimer64 syscall so we need to make
> > > > > > sure we pass a 32-bit time_t here. If __TIMESIZE == 32 then we
> > > > > > don't need any changes and can just directly make the syscall
> > > > > > (as we do in this patch). The conversion is only required if
> > > > > > __TIMESIZE == 64 as we need to convert to/from a 32-bit
> > > > > > time_t.
> > > > >
> > > > > This is a point about the general structure and goals of the
> > > > > Y2038 work.
> > > > >
> > > > > We want to end up at a point where, on systems where time_t is
> > > > > currently 32-bit, you can build with -D_TIME_BITS=64 and get
> > > > > 64-bit time_t instead. That means that all time-related
> > > > > functions, including getitimer and setitimer, will, on such
> > > > > systems, need to have two implementations in glibc, one using
> > > > > 64-bit times and one using 32-bit times.
> > > >
> > > > I'm still confused. If we build with -D_TIME_BITS=64 does that
> > > > then mean that __TIMESIZE == 64 ?
> > > >
> > > > In which case the user exposed time_t is 64-bit and these calls
> > > > will take a 64-bit time_t and convert it to/from a 32-bit time_t
> > > > to pass to the kernel. The user will only ever use/see a 64-bit
> > > > time_t.
> > > > >
> > > > > The implementation structure generally being used is that the
> > > > > main implementation has an interface using 64-bit times (even
> > > > > if it ends up using syscalls with 32-bit times) and the one
> > > > > using 32-bit times is a thin
> > > >
> > > > Isn't that what is happening here when __TIMESIZE == 64 ?
> > > >
> > > > > wrapper around it (if time_t is already 64-bit, the second
> > > > > implementation does not exist and some macros ensure the first
> > > > > implementation keeps its existing name). Once all functions
> > > > > have been moved to that structure, we can set things up so that
> > > > > all those 64-bit functions are exported from glibc and add
> > > > > _TIME_BITS support in the headers.
> > > >
> > > > Ah, do you mean that glibc should expose a 64-bit time_t version
> > > > if __TIMESIZE == 32?
> > >
> > > Yes, exactly.
> > >
> > > Currently 32 bit ARM (__WORDSIZE == 32 && __TIMESIZE == 32) use 32
> > > bit time_t. However, after compiling the source code with
> > > -D_TIME_BITS=64 the time_t will become 64 bit.
> > >
> > > Please find example setup for tests_y2038:
> > > https://github.com/lmajewski/y2038-tests/blob/master/Makefile#L25
> > > (Two binaries are build from the same sources - one is Y2038 safe
> > > and other is not).
> > >
> > > The notable difference between the new RV32 port and existing ARM32
> > > is that for new ports (i.e. RV32) the __TIMESIZE = 64 is set from
> > > the outset.
> > > For the latter (ARM32) the __TIMESIZE = 32 is kept and IIRC we will
> > > NOT update it to __TIMESIZE = 64 anytime soon. Instead, in exported
> > > headers _TIME_BITS=64 will be set by default (approach similar to
> > > the one for _FILE_OFFSET_BITS=64).
> >
> > Doesn't that mean that I can fix this all by just using if _TIME_BITS
> > == 64 instead of __TIMESIZE?
>
> Unfortunately, not. The _TIME_BITS define affects _exported_ glibc
> headers. It sets __USE_TIME_BITS64, which shall NOT be used in glibc
> internals:
> https://github.com/lmajewski/y2038_glibc/commit/319c24507974fecdffe5182d310289b2a4cb9122#diff-a5ab6c74681eaf0569ed54f6bf0d7978R391
>
>
> Instead, the glibc shall be prepared for handling those syscalls
> correctly in both cases - when _TIME_BITS == 64 (Y2038 safe) is defined
> or not during the compilation.
>
> >
> > >
> > > Joseph, am I right?
> > >
> > > > So even __TIMESIZE == 32 systems can call a 64-bit
> > > > time_t version (even if the syscall ends up being 32-bit).
> > >
> > > +1
> >
> > Even if time_t is 64-bit you can't pass a value larger then 32-bits to
> > these functions as they get converted back to a 32-bit value for the
> > kernel syscall.
>
> The problem is with consistency:
>
> 1. Internally glibc is going to replace time_t (which may be 32 bit)
> with __time64_t (as it is done indirectly with introduction of struct
> __timespec64, etc). In that way glibc will be itself Y2038 safe no
> matter of __TIMESIZE value (32, 64 bit).
>
> 2. The functions with 64 suffix (i.e. __getitimer64, __settime64)
>
> e.g.:
>
> int
> __getitimer64 (__itimer_which_t which, struct __itimerval64 *curr_value)
>
> Will use struct __itimerval64, which will always support 64 bit time
> (the same situation as with struct __itimerspec64).
>
>
> Afterwards, I will define redirection for it in the exported headers -
> like for example here (for timerspec_get):
> https://github.com/lmajewski/y2038_glibc/commit/9844cb7beb854e21bbdc595398627777b6155c27#diff-07934c1fe09f0e6357413e138856c786R320
>
> This redirection will force usage of __gettimer64 on ARM32 bit
> (__TIMESIZE==32 && __WORDSIZE==32) when -D_TIME_BITS=64 is set during
> compilation.
>
> (I'm now finishing patches to introduce struct __timeval64 to glibc)
>
>
> >
> > >
> > > Please find example conversion code for timespec_get conversion:
> > > https://patchwork.ozlabs.org/patch/1224222/
> > >
> > > it internally uses __clock_gettime64, which uses 64 bit time no
> > > matter on which architecture it runs (even with __TIMESIZE==32).
> >
> > In this case though the syscall is always 32-bit, so I'm not sure if
> > there is a huge advantage here.
>
> The advantage is that the consistency of function conversion will be
> preserved. The __gettimer64 function will be used, even though we will
> use 32 bit syscalls and when kernel (maybe?) introduce 64 bit syscalls
> we will be ready.
>
> >
> > I don't see a point of converting this function to take a 64-bit value
> > if time_t is 32-bit as that doesn't give you anything.
>
> time_t may be 32 bit or 64 on the Y2038 safe systems. It depends on
> adding -D_TIME_BITS=64 during compilation.
>
> > It does seem
> > worth changing the #if to check _TIME_BITS == 64 instead of __TIMESIZE
> > though.
>
> As I've stated above - the _TIME_BITS (and __USE_TIME_BITS64) are
> supposed to be "visible" in the glibc exported headers.
> The __USE_TIME_BITS64 flag enables redirection for the syscalls:
> https://github.com/lmajewski/y2038_glibc/commit/319c24507974fecdffe5182d310289b2a4cb9122#diff-8bdb75c23cf534160b06f2dc2183e971R67
>
> On the glibc side one shall have time functions converted to:
> https://github.com/lmajewski/y2038_glibc/commit/6367f6e061c5184b39cf7fff07ffcf8b569d765e#diff-a8bb3b17dcb4b2b40deba97323563301R33
Thanks for clarifying that. I think I understand now.
So basically follow the other implementations (or the link directly
above) and add a __getitimer64/__setitimer64 function and a wrapper
__getitimer/__setitimer for the current 32-bit time_t.
Alistair
>
>
> >
> > Alistair
> >
> > >
> > > Please also refer to the branch, which moves 32 bit ports closer to
> > > being Y2038 safe:
> > >
> > > https://github.com/lmajewski/y2038_glibc/commits/glibc_timespec_get-conversion-v1
> > >
> > > >
> > > > Alistair
> > > >
> > > > >
> > > > > --
> > > > > Joseph S. Myers
> > > > > joseph@codesourcery.com
> > >
> > >
> > >
> > >
> > > 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
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 04/23] linux: Use 32-bit time_t for itimerval
2020-01-17 12:03 ` Alistair Francis
@ 2020-01-17 12:19 ` Lukasz Majewski
2020-01-17 14:14 ` Joseph Myers
1 sibling, 0 replies; 138+ messages in thread
From: Lukasz Majewski @ 2020-01-17 12:19 UTC (permalink / raw)
To: Alistair Francis
Cc: Joseph Myers, Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
[-- Attachment #1: Type: text/plain, Size: 9676 bytes --]
Hi Alistair,
> On Fri, Jan 17, 2020 at 9:14 PM Lukasz Majewski <lukma@denx.de> wrote:
> >
> > Hi Alistair,
> >
> > > On Thu, Jan 16, 2020 at 11:34 PM Lukasz Majewski <lukma@denx.de>
> > > wrote:
> > > >
> > > > Hi Alistair, Joseph
> > > >
> > > > > On Thu, Jan 16, 2020 at 11:21 AM Joseph Myers
> > > > > <joseph@codesourcery.com> wrote:
> > > > > >
> > > > > > On Thu, 16 Jan 2020, Alistair Francis wrote:
> > > > > >
> > > > > > > > To allow it this syscall wrapper shall be converted
> > > > > > > > (written) in the same way as e.g:
> > > > > > > >
> > > > > > > > ./sysdeps/unix/sysv/linux/clock_settime.c
> > > > > > > >
> > > > > > > > (the same issue is with getitimer).
> > > > > > > >
> > > > > > > > Then only redirection when __USE_TIME_BITS64 is set are
> > > > > > > > needed to use __setitimer64/__getitimer64 on Y2038 safe
> > > > > > > > systems.
> > > > > > >
> > > > > > > I'm not sure what you mean here.
> > > > > > >
> > > > > > > There is no setitimer64/getitimer64 syscall so we need to
> > > > > > > make sure we pass a 32-bit time_t here. If __TIMESIZE ==
> > > > > > > 32 then we don't need any changes and can just directly
> > > > > > > make the syscall (as we do in this patch). The conversion
> > > > > > > is only required if __TIMESIZE == 64 as we need to
> > > > > > > convert to/from a 32-bit time_t.
> > > > > >
> > > > > > This is a point about the general structure and goals of the
> > > > > > Y2038 work.
> > > > > >
> > > > > > We want to end up at a point where, on systems where time_t
> > > > > > is currently 32-bit, you can build with -D_TIME_BITS=64 and
> > > > > > get 64-bit time_t instead. That means that all time-related
> > > > > > functions, including getitimer and setitimer, will, on such
> > > > > > systems, need to have two implementations in glibc, one
> > > > > > using 64-bit times and one using 32-bit times.
> > > > >
> > > > > I'm still confused. If we build with -D_TIME_BITS=64 does that
> > > > > then mean that __TIMESIZE == 64 ?
> > > > >
> > > > > In which case the user exposed time_t is 64-bit and these
> > > > > calls will take a 64-bit time_t and convert it to/from a
> > > > > 32-bit time_t to pass to the kernel. The user will only ever
> > > > > use/see a 64-bit time_t.
> > > > > >
> > > > > > The implementation structure generally being used is that
> > > > > > the main implementation has an interface using 64-bit times
> > > > > > (even if it ends up using syscalls with 32-bit times) and
> > > > > > the one using 32-bit times is a thin
> > > > >
> > > > > Isn't that what is happening here when __TIMESIZE == 64 ?
> > > > >
> > > > > > wrapper around it (if time_t is already 64-bit, the second
> > > > > > implementation does not exist and some macros ensure the
> > > > > > first implementation keeps its existing name). Once all
> > > > > > functions have been moved to that structure, we can set
> > > > > > things up so that all those 64-bit functions are exported
> > > > > > from glibc and add _TIME_BITS support in the headers.
> > > > >
> > > > > Ah, do you mean that glibc should expose a 64-bit time_t
> > > > > version if __TIMESIZE == 32?
> > > >
> > > > Yes, exactly.
> > > >
> > > > Currently 32 bit ARM (__WORDSIZE == 32 && __TIMESIZE == 32) use
> > > > 32 bit time_t. However, after compiling the source code with
> > > > -D_TIME_BITS=64 the time_t will become 64 bit.
> > > >
> > > > Please find example setup for tests_y2038:
> > > > https://github.com/lmajewski/y2038-tests/blob/master/Makefile#L25
> > > > (Two binaries are build from the same sources - one is Y2038
> > > > safe and other is not).
> > > >
> > > > The notable difference between the new RV32 port and existing
> > > > ARM32 is that for new ports (i.e. RV32) the __TIMESIZE = 64 is
> > > > set from the outset.
> > > > For the latter (ARM32) the __TIMESIZE = 32 is kept and IIRC we
> > > > will NOT update it to __TIMESIZE = 64 anytime soon. Instead, in
> > > > exported headers _TIME_BITS=64 will be set by default (approach
> > > > similar to the one for _FILE_OFFSET_BITS=64).
> > >
> > > Doesn't that mean that I can fix this all by just using if
> > > _TIME_BITS == 64 instead of __TIMESIZE?
> >
> > Unfortunately, not. The _TIME_BITS define affects _exported_ glibc
> > headers. It sets __USE_TIME_BITS64, which shall NOT be used in glibc
> > internals:
> > https://github.com/lmajewski/y2038_glibc/commit/319c24507974fecdffe5182d310289b2a4cb9122#diff-a5ab6c74681eaf0569ed54f6bf0d7978R391
> >
> >
> > Instead, the glibc shall be prepared for handling those syscalls
> > correctly in both cases - when _TIME_BITS == 64 (Y2038 safe) is
> > defined or not during the compilation.
> >
> > >
> > > >
> > > > Joseph, am I right?
> > > >
> > > > > So even __TIMESIZE == 32 systems can call a 64-bit
> > > > > time_t version (even if the syscall ends up being 32-bit).
> > > >
> > > > +1
> > >
> > > Even if time_t is 64-bit you can't pass a value larger then
> > > 32-bits to these functions as they get converted back to a 32-bit
> > > value for the kernel syscall.
> >
> > The problem is with consistency:
> >
> > 1. Internally glibc is going to replace time_t (which may be 32 bit)
> > with __time64_t (as it is done indirectly with introduction of
> > struct __timespec64, etc). In that way glibc will be itself Y2038
> > safe no matter of __TIMESIZE value (32, 64 bit).
> >
> > 2. The functions with 64 suffix (i.e. __getitimer64, __settime64)
> >
> > e.g.:
> >
> > int
> > __getitimer64 (__itimer_which_t which, struct __itimerval64
> > *curr_value)
> >
> > Will use struct __itimerval64, which will always support 64 bit time
> > (the same situation as with struct __itimerspec64).
> >
> >
> > Afterwards, I will define redirection for it in the exported
> > headers - like for example here (for timerspec_get):
> > https://github.com/lmajewski/y2038_glibc/commit/9844cb7beb854e21bbdc595398627777b6155c27#diff-07934c1fe09f0e6357413e138856c786R320
> >
> > This redirection will force usage of __gettimer64 on ARM32 bit
> > (__TIMESIZE==32 && __WORDSIZE==32) when -D_TIME_BITS=64 is set
> > during compilation.
> >
> > (I'm now finishing patches to introduce struct __timeval64 to glibc)
> >
> >
> > >
> > > >
> > > > Please find example conversion code for timespec_get conversion:
> > > > https://patchwork.ozlabs.org/patch/1224222/
> > > >
> > > > it internally uses __clock_gettime64, which uses 64 bit time no
> > > > matter on which architecture it runs (even with
> > > > __TIMESIZE==32).
> > >
> > > In this case though the syscall is always 32-bit, so I'm not sure
> > > if there is a huge advantage here.
> >
> > The advantage is that the consistency of function conversion will be
> > preserved. The __gettimer64 function will be used, even though we
> > will use 32 bit syscalls and when kernel (maybe?) introduce 64 bit
> > syscalls we will be ready.
> >
> > >
> > > I don't see a point of converting this function to take a 64-bit
> > > value if time_t is 32-bit as that doesn't give you anything.
> >
> > time_t may be 32 bit or 64 on the Y2038 safe systems. It depends on
> > adding -D_TIME_BITS=64 during compilation.
> >
> > > It does seem
> > > worth changing the #if to check _TIME_BITS == 64 instead of
> > > __TIMESIZE though.
> >
> > As I've stated above - the _TIME_BITS (and __USE_TIME_BITS64) are
> > supposed to be "visible" in the glibc exported headers.
> > The __USE_TIME_BITS64 flag enables redirection for the syscalls:
> > https://github.com/lmajewski/y2038_glibc/commit/319c24507974fecdffe5182d310289b2a4cb9122#diff-8bdb75c23cf534160b06f2dc2183e971R67
> >
> > On the glibc side one shall have time functions converted to:
> > https://github.com/lmajewski/y2038_glibc/commit/6367f6e061c5184b39cf7fff07ffcf8b569d765e#diff-a8bb3b17dcb4b2b40deba97323563301R33
> >
>
> Thanks for clarifying that. I think I understand now.
>
> So basically follow the other implementations (or the link directly
> above) and add a __getitimer64/__setitimer64 function and a wrapper
> __getitimer/__setitimer for the current 32-bit time_t.
Yes, exactly. :-)
>
> Alistair
>
> >
> >
> > >
> > > Alistair
> > >
> > > >
> > > > Please also refer to the branch, which moves 32 bit ports
> > > > closer to being Y2038 safe:
> > > >
> > > > https://github.com/lmajewski/y2038_glibc/commits/glibc_timespec_get-conversion-v1
> > > >
> > > > >
> > > > > Alistair
> > > > >
> > > > > >
> > > > > > --
> > > > > > Joseph S. Myers
> > > > > > joseph@codesourcery.com
> > > >
> > > >
> > > >
> > > >
> > > > 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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 04/23] linux: Use 32-bit time_t for itimerval
2020-01-17 12:03 ` Alistair Francis
2020-01-17 12:19 ` Lukasz Majewski
@ 2020-01-17 14:14 ` Joseph Myers
1 sibling, 0 replies; 138+ messages in thread
From: Joseph Myers @ 2020-01-17 14:14 UTC (permalink / raw)
To: Alistair Francis
Cc: Lukasz Majewski, Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Fri, 17 Jan 2020, Alistair Francis wrote:
> So basically follow the other implementations (or the link directly
> above) and add a __getitimer64/__setitimer64 function and a wrapper
> __getitimer/__setitimer for the current 32-bit time_t.
Yes.
We are in the middle of a very long series of patches - maybe ending up as
hundreds of patches - that *prepare* for adding support for _TIME_BITS=64.
None of those patches actually contain any _TIME_BITS or __USE_TIME_BITS64
conditionals, because it's important that users of glibc get a consistent
API (we don't want an intermediate state where defining _TIME_BITS=64
gives users a broken interface where different functions have different
notions of time_t, for example). But new patches relating to 64-bit times
should be consistent with the design of support for 64-bit time on systems
that currently use 32-bit time. And that means having a main function
that uses 64-bit times in its interface, and on systems with 32-bit time,
a thin wrapper that converts 32-bit times to 64-bit.
This design becomes particularly important when we get to functions that
involve hundreds of lines of glibc code rather than thin wrappers round
syscalls - for example, some pthreads functions.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 04/23] linux: Use 32-bit time_t for itimerval
2020-01-16 1:33 ` Alistair Francis
2020-01-16 13:34 ` Lukasz Majewski
@ 2020-01-16 16:19 ` Joseph Myers
2020-01-17 6:40 ` Alistair Francis
1 sibling, 1 reply; 138+ messages in thread
From: Joseph Myers @ 2020-01-16 16:19 UTC (permalink / raw)
To: Alistair Francis
Cc: Lukasz Majewski, Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Thu, 16 Jan 2020, Alistair Francis wrote:
> > We want to end up at a point where, on systems where time_t is currently
> > 32-bit, you can build with -D_TIME_BITS=64 and get 64-bit time_t instead.
> > That means that all time-related functions, including getitimer and
> > setitimer, will, on such systems, need to have two implementations in
> > glibc, one using 64-bit times and one using 32-bit times.
>
> I'm still confused. If we build with -D_TIME_BITS=64 does that then
> mean that __TIMESIZE == 64 ?
No. The semantics of __TIMESIZE are defined in the comment on
bits/timesize.h. It refers to the *default ABI*, not to any different ABI
resulting from a setting of _TIME_BITS. -D_TIME_BITS=64 will result in
64-bit time_t, but it will not change __TIMESIZE.
> > The implementation structure generally being used is that the main
> > implementation has an interface using 64-bit times (even if it ends up
> > using syscalls with 32-bit times) and the one using 32-bit times is a thin
>
> Isn't that what is happening here when __TIMESIZE == 64 ?
If __TIMESIZE == 64, the thin wrapper does not exist, because there's a
"#if __TIMESIZE != 64" conditional around it (see e.g.
sysdeps/unix/sysv/linux/clock_settime.c for the desired structure).
> > wrapper around it (if time_t is already 64-bit, the second implementation
> > does not exist and some macros ensure the first implementation keeps its
> > existing name). Once all functions have been moved to that structure, we
> > can set things up so that all those 64-bit functions are exported from
> > glibc and add _TIME_BITS support in the headers.
>
> Ah, do you mean that glibc should expose a 64-bit time_t version if
> __TIMESIZE == 32? So even __TIMESIZE == 32 systems can call a 64-bit
> time_t version (even if the syscall ends up being 32-bit).
Eventually glibc should expose all those 64-bit time_t versions.
Right now, when __TIMESIZE == 32 those versions should be defined, and
called by the thin wrappers for 32-bit time_t, but not exported at public
symbol version (until all of them exist and all the header changes are
ready).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 04/23] linux: Use 32-bit time_t for itimerval
2020-01-16 16:19 ` Joseph Myers
@ 2020-01-17 6:40 ` Alistair Francis
0 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-17 6:40 UTC (permalink / raw)
To: Joseph Myers
Cc: Lukasz Majewski, Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Fri, Jan 17, 2020 at 2:19 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 16 Jan 2020, Alistair Francis wrote:
>
> > > We want to end up at a point where, on systems where time_t is currently
> > > 32-bit, you can build with -D_TIME_BITS=64 and get 64-bit time_t instead.
> > > That means that all time-related functions, including getitimer and
> > > setitimer, will, on such systems, need to have two implementations in
> > > glibc, one using 64-bit times and one using 32-bit times.
> >
> > I'm still confused. If we build with -D_TIME_BITS=64 does that then
> > mean that __TIMESIZE == 64 ?
>
> No. The semantics of __TIMESIZE are defined in the comment on
> bits/timesize.h. It refers to the *default ABI*, not to any different ABI
> resulting from a setting of _TIME_BITS. -D_TIME_BITS=64 will result in
> 64-bit time_t, but it will not change __TIMESIZE.
>
> > > The implementation structure generally being used is that the main
> > > implementation has an interface using 64-bit times (even if it ends up
> > > using syscalls with 32-bit times) and the one using 32-bit times is a thin
> >
> > Isn't that what is happening here when __TIMESIZE == 64 ?
>
> If __TIMESIZE == 64, the thin wrapper does not exist, because there's a
> "#if __TIMESIZE != 64" conditional around it (see e.g.
> sysdeps/unix/sysv/linux/clock_settime.c for the desired structure).
>
> > > wrapper around it (if time_t is already 64-bit, the second implementation
> > > does not exist and some macros ensure the first implementation keeps its
> > > existing name). Once all functions have been moved to that structure, we
> > > can set things up so that all those 64-bit functions are exported from
> > > glibc and add _TIME_BITS support in the headers.
> >
> > Ah, do you mean that glibc should expose a 64-bit time_t version if
> > __TIMESIZE == 32? So even __TIMESIZE == 32 systems can call a 64-bit
> > time_t version (even if the syscall ends up being 32-bit).
>
> Eventually glibc should expose all those 64-bit time_t versions.
In this case won't that just happen automatically when _TIME_BITS is
64 (64-bit time_t)?
>
> Right now, when __TIMESIZE == 32 those versions should be defined, and
> called by the thin wrappers for 32-bit time_t, but not exported at public
> symbol version (until all of them exist and all the header changes are
> ready).
In this case though there is no 64-bit time_t syscall (we only have
32-bit even with 64-bit time_t) so why expose a 64-bit version?
Alistair
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* [RFC v6 05/23] linux: Use 32-bit time_t for rusage
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (3 preceding siblings ...)
2020-01-12 10:33 ` [RFC v6 04/23] linux: Use 32-bit time_t for itimerval Alistair Francis
@ 2020-01-12 10:33 ` Alistair Francis
2020-01-14 11:58 ` Lukasz Majewski
2020-01-12 10:33 ` [RFC v6 06/23] sysdeps: Use long types with 64-bit time_t on 32-bit archs Alistair Francis
` (18 subsequent siblings)
23 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:33 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
The Linux kernel expects rusage to use a 32-bit time_t, even on archs
with a 64-bit time_t (like RV32). To address this let's convert
rusage to/from 32-bit and 64-bit to ensure the kernel always gets
a 32-bit time_t.
This means that all 32-bit architectures with a 64-bit time_t will be
able to use this generic implementation.
This code is bsaed on similar code in alpha, but adjusted to pass the
32-bit time_t to the kernel.
We can't directly call __wait4 as it expects a structrusage but we have
to pass in and use a struct rusage32. The same appies to __getrusage.
---
.../linux/generic/wordsize-32/getrusage.c | 39 +++++++++
.../linux/generic/wordsize-32/tv32-compat.h | 47 +++++++++++
.../sysv/linux/generic/wordsize-32/wait4.c | 79 +++++++++++++++++++
3 files changed, 165 insertions(+)
create mode 100644 sysdeps/unix/sysv/linux/generic/wordsize-32/getrusage.c
create mode 100644 sysdeps/unix/sysv/linux/generic/wordsize-32/wait4.c
diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/getrusage.c b/sysdeps/unix/sysv/linux/generic/wordsize-32/getrusage.c
new file mode 100644
index 0000000000..2ada94a954
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/getrusage.c
@@ -0,0 +1,39 @@
+/* utimes -- change file timestamps. Linux/RV32/tv32 version.
+ Copyright (C) 2020 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 <sys/time.h>
+#include <sys/resource.h>
+#include <sysdep.h>
+#include <tv32-compat.h>
+
+int
+__getrusage (int who, struct rusage *usage)
+{
+#if __TIMESIZE == 64
+ struct rusage32 usage32;
+ if (INLINE_SYSCALL_CALL (getrusage, who, &usage32) == -1)
+ return -1;
+
+ rusage32_to_rusage64 (&usage32, usage);
+ return 0;
+#else
+ return INLINE_SYSCALL_CALL (getrusage, who, usage);
+#endif
+}
+
+strong_alias (__getrusage, getrusage)
diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h b/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h
index aa960a6632..8a4bd15002 100644
--- a/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h
+++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h
@@ -24,6 +24,7 @@
#include <bits/types.h>
#include <bits/types/time_t.h>
#include <bits/types/struct_timeval.h>
+#include <bits/types/struct_rusage.h>
/* Structures containing 'struct timeval' with 32-bit time_t. */
struct itimerval32
@@ -32,4 +33,50 @@ struct itimerval32
struct __timeval_long it_value;
};
+struct rusage32
+{
+ struct __timeval_long ru_utime; /* user time used */
+ struct __timeval_long ru_stime; /* system time used */
+ long ru_maxrss; /* maximum resident set size */
+ long ru_ixrss; /* integral shared memory size */
+ long ru_idrss; /* integral unshared data size */
+ long ru_isrss; /* integral unshared stack size */
+ long ru_minflt; /* page reclaims */
+ long ru_majflt; /* page faults */
+ long ru_nswap; /* swaps */
+ long ru_inblock; /* block input operations */
+ long ru_oublock; /* block output operations */
+ long ru_msgsnd; /* messages sent */
+ long ru_msgrcv; /* messages received */
+ long ru_nsignals; /* signals received */
+ long ru_nvcsw; /* voluntary context switches */
+ long ru_nivcsw; /* involuntary " */
+};
+
+static inline void
+rusage32_to_rusage64 (const struct rusage32 *restrict r32,
+ struct rusage *restrict r64)
+{
+ /* Make sure the entire output structure is cleared, including
+ padding and reserved fields. */
+ memset (r64, 0, sizeof *r64);
+
+ r64->ru_utime = valid_timeval_long_to_timeval64 (r32->ru_utime);
+ r64->ru_stime = valid_timeval_long_to_timeval64 (r32->ru_stime);
+ r64->ru_maxrss = r32->ru_maxrss;
+ r64->ru_ixrss = r32->ru_ixrss;
+ r64->ru_idrss = r32->ru_idrss;
+ r64->ru_isrss = r32->ru_isrss;
+ r64->ru_minflt = r32->ru_minflt;
+ r64->ru_majflt = r32->ru_majflt;
+ r64->ru_nswap = r32->ru_nswap;
+ r64->ru_inblock = r32->ru_inblock;
+ r64->ru_oublock = r32->ru_oublock;
+ r64->ru_msgsnd = r32->ru_msgsnd;
+ r64->ru_msgrcv = r32->ru_msgrcv;
+ r64->ru_nsignals = r32->ru_nsignals;
+ r64->ru_nvcsw = r32->ru_nvcsw;
+ r64->ru_nivcsw = r32->ru_nivcsw;
+}
+
#endif /* tv32-compat.h */
diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/wait4.c b/sysdeps/unix/sysv/linux/generic/wordsize-32/wait4.c
new file mode 100644
index 0000000000..a4a81a0587
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/wait4.c
@@ -0,0 +1,79 @@
+/* wait4 -- wait for process to change state. Linux/RV32/tv32 version.
+ Copyright (C) 2020 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 <sys/wait.h>
+#include <sys/resource.h>
+#include <sysdep-cancel.h>
+#include <tv32-compat.h>
+
+pid_t
+__wait4 (pid_t pid, int *stat_loc, int options, struct rusage *usage)
+{
+ struct rusage32 usage32;
+ idtype_t idtype = P_PID;
+
+ if (pid < -1)
+ {
+ idtype = P_PGID;
+ pid *= -1;
+ }
+ else if (pid == -1)
+ idtype = P_ALL;
+ else if (pid == 0)
+ idtype = P_PGID;
+
+ options |= WEXITED;
+
+ siginfo_t infop;
+ if (SYSCALL_CANCEL (waitid, idtype, pid, &infop, options, &usage32) < 0)
+ return -1;
+
+ if (stat_loc)
+ {
+ switch (infop.si_code)
+ {
+ case CLD_EXITED:
+ *stat_loc = W_EXITCODE (infop.si_status, 0);
+ break;
+ case CLD_DUMPED:
+ *stat_loc = WCOREFLAG | infop.si_status;
+ break;
+ case CLD_KILLED:
+ *stat_loc = infop.si_status;
+ break;
+ case CLD_TRAPPED:
+ case CLD_STOPPED:
+ *stat_loc = W_STOPCODE (infop.si_status);
+ break;
+ case CLD_CONTINUED:
+ *stat_loc = __W_CONTINUED;
+ break;
+ default:
+ *stat_loc = 0;
+ break;
+ }
+ }
+
+ if (usage != NULL)
+ rusage32_to_rusage64 (&usage32, usage);
+
+ return infop.si_pid;
+}
+
+libc_hidden_def (__wait4);
+weak_alias (__wait4, wait4)
--
2.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* Re: [RFC v6 05/23] linux: Use 32-bit time_t for rusage
2020-01-12 10:33 ` [RFC v6 05/23] linux: Use 32-bit time_t for rusage Alistair Francis
@ 2020-01-14 11:58 ` Lukasz Majewski
2020-01-15 23:42 ` Alistair Francis
0 siblings, 1 reply; 138+ messages in thread
From: Lukasz Majewski @ 2020-01-14 11:58 UTC (permalink / raw)
To: Alistair Francis
Cc: libc-alpha, arnd, adhemerval.zanella, fweimer, joseph,
palmerdabbelt, macro, zongbox, alistair23
[-- Attachment #1: Type: text/plain, Size: 8975 bytes --]
Hi Alistair,
> The Linux kernel expects rusage to use a 32-bit time_t, even on archs
> with a 64-bit time_t (like RV32). To address this let's convert
> rusage to/from 32-bit and 64-bit to ensure the kernel always gets
> a 32-bit time_t.
>
> This means that all 32-bit architectures with a 64-bit time_t will be
> able to use this generic implementation.
>
> This code is bsaed on similar code in alpha, but adjusted to pass the
^^^^^ - based?
> 32-bit time_t to the kernel.
>
> We can't directly call __wait4 as it expects a structrusage but we
^^^^^^^^^^^^ - struct
rusage
> have to pass in and use a struct rusage32. The same appies to
> __getrusage. ---
> .../linux/generic/wordsize-32/getrusage.c | 39 +++++++++
> .../linux/generic/wordsize-32/tv32-compat.h | 47 +++++++++++
> .../sysv/linux/generic/wordsize-32/wait4.c | 79
> +++++++++++++++++++ 3 files changed, 165 insertions(+)
> create mode 100644
> sysdeps/unix/sysv/linux/generic/wordsize-32/getrusage.c create mode
> 100644 sysdeps/unix/sysv/linux/generic/wordsize-32/wait4.c
>
> diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/getrusage.c
> b/sysdeps/unix/sysv/linux/generic/wordsize-32/getrusage.c new file
> mode 100644 index 0000000000..2ada94a954
> --- /dev/null
> +++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/getrusage.c
> @@ -0,0 +1,39 @@
> +/* utimes -- change file timestamps. Linux/RV32/tv32 version.
Please update the in-comment header.
> + Copyright (C) 2020 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 <sys/time.h>
> +#include <sys/resource.h>
> +#include <sysdep.h>
> +#include <tv32-compat.h>
> +
> +int
> +__getrusage (int who, struct rusage *usage)
> +{
> +#if __TIMESIZE == 64
> + struct rusage32 usage32;
> + if (INLINE_SYSCALL_CALL (getrusage, who, &usage32) == -1)
> + return -1;
> +
> + rusage32_to_rusage64 (&usage32, usage);
> + return 0;
> +#else
> + return INLINE_SYSCALL_CALL (getrusage, who, usage);
> +#endif
> +}
This is the same issue as pointed out with __setitimer support.
Following the conversion convention (as in e.g. clock_settime.c) would
allow Y2038 safe 32 bit ports benefit from this patch.
> +
> +strong_alias (__getrusage, getrusage)
> diff --git
> a/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h
> b/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h index
> aa960a6632..8a4bd15002 100644 ---
> a/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h +++
> b/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h @@ -24,6
> +24,7 @@ #include <bits/types.h> #include <bits/types/time_t.h>
> #include <bits/types/struct_timeval.h>
> +#include <bits/types/struct_rusage.h>
>
> /* Structures containing 'struct timeval' with 32-bit time_t. */
> struct itimerval32
> @@ -32,4 +33,50 @@ struct itimerval32
> struct __timeval_long it_value;
> };
>
> +struct rusage32
struct __rusage32 ?
> +{
> + struct __timeval_long ru_utime; /* user time used */
> + struct __timeval_long ru_stime; /* system time used */
As pointed out in the other comment - maybe struct
__timeval32 would be more appropriate?
This is the same convention as we already have with struct
__timespec64 and __itimerspec64
> + long ru_maxrss; /* maximum resident set size */
> + long ru_ixrss; /* integral shared memory size */
> + long ru_idrss; /* integral unshared data size */
> + long ru_isrss; /* integral unshared stack size */
> + long ru_minflt; /* page reclaims */
> + long ru_majflt; /* page faults */
> + long ru_nswap; /* swaps */
> + long ru_inblock; /* block input operations */
> + long ru_oublock; /* block output operations */
> + long ru_msgsnd; /* messages sent */
> + long ru_msgrcv; /* messages received */
> + long ru_nsignals; /* signals received */
> + long ru_nvcsw; /* voluntary context switches */
> + long ru_nivcsw; /* involuntary " */
> +};
> +
> +static inline void
> +rusage32_to_rusage64 (const struct rusage32 *restrict r32,
> + struct rusage *restrict r64)
> +{
> + /* Make sure the entire output structure is cleared, including
> + padding and reserved fields. */
> + memset (r64, 0, sizeof *r64);
> +
> + r64->ru_utime = valid_timeval_long_to_timeval64 (r32->ru_utime);
> + r64->ru_stime = valid_timeval_long_to_timeval64 (r32->ru_stime);
> + r64->ru_maxrss = r32->ru_maxrss;
> + r64->ru_ixrss = r32->ru_ixrss;
> + r64->ru_idrss = r32->ru_idrss;
> + r64->ru_isrss = r32->ru_isrss;
> + r64->ru_minflt = r32->ru_minflt;
> + r64->ru_majflt = r32->ru_majflt;
> + r64->ru_nswap = r32->ru_nswap;
> + r64->ru_inblock = r32->ru_inblock;
> + r64->ru_oublock = r32->ru_oublock;
> + r64->ru_msgsnd = r32->ru_msgsnd;
> + r64->ru_msgrcv = r32->ru_msgrcv;
> + r64->ru_nsignals = r32->ru_nsignals;
> + r64->ru_nvcsw = r32->ru_nvcsw;
> + r64->ru_nivcsw = r32->ru_nivcsw;
> +}
> +
> #endif /* tv32-compat.h */
> diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/wait4.c
> b/sysdeps/unix/sysv/linux/generic/wordsize-32/wait4.c new file mode
> 100644 index 0000000000..a4a81a0587
> --- /dev/null
> +++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/wait4.c
> @@ -0,0 +1,79 @@
> +/* wait4 -- wait for process to change state. Linux/RV32/tv32
> version.
> + Copyright (C) 2020 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 <sys/wait.h>
> +#include <sys/resource.h>
> +#include <sysdep-cancel.h>
> +#include <tv32-compat.h>
> +
> +pid_t
> +__wait4 (pid_t pid, int *stat_loc, int options, struct rusage *usage)
> +{
> + struct rusage32 usage32;
> + idtype_t idtype = P_PID;
> +
> + if (pid < -1)
> + {
> + idtype = P_PGID;
> + pid *= -1;
> + }
> + else if (pid == -1)
> + idtype = P_ALL;
> + else if (pid == 0)
> + idtype = P_PGID;
> +
> + options |= WEXITED;
> +
> + siginfo_t infop;
> + if (SYSCALL_CANCEL (waitid, idtype, pid, &infop, options,
> &usage32) < 0)
> + return -1;
> +
> + if (stat_loc)
> + {
> + switch (infop.si_code)
> + {
> + case CLD_EXITED:
> + *stat_loc = W_EXITCODE (infop.si_status, 0);
> + break;
> + case CLD_DUMPED:
> + *stat_loc = WCOREFLAG | infop.si_status;
> + break;
> + case CLD_KILLED:
> + *stat_loc = infop.si_status;
> + break;
> + case CLD_TRAPPED:
> + case CLD_STOPPED:
> + *stat_loc = W_STOPCODE (infop.si_status);
> + break;
> + case CLD_CONTINUED:
> + *stat_loc = __W_CONTINUED;
> + break;
> + default:
> + *stat_loc = 0;
> + break;
> + }
> + }
> +
> + if (usage != NULL)
> + rusage32_to_rusage64 (&usage32, usage);
> +
> + return infop.si_pid;
> +}
> +
> +libc_hidden_def (__wait4);
> +weak_alias (__wait4, wait4)
This wait4 implementation (as it doesn't use #define __TIMESIZE == 64)
could be used by all 32 bit ports. Am I right?
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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 05/23] linux: Use 32-bit time_t for rusage
2020-01-14 11:58 ` Lukasz Majewski
@ 2020-01-15 23:42 ` Alistair Francis
0 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-15 23:42 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Joseph Myers, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Tue, Jan 14, 2020 at 9:58 PM Lukasz Majewski <lukma@denx.de> wrote:
>
> Hi Alistair,
>
> > The Linux kernel expects rusage to use a 32-bit time_t, even on archs
> > with a 64-bit time_t (like RV32). To address this let's convert
> > rusage to/from 32-bit and 64-bit to ensure the kernel always gets
> > a 32-bit time_t.
> >
> > This means that all 32-bit architectures with a 64-bit time_t will be
> > able to use this generic implementation.
> >
> > This code is bsaed on similar code in alpha, but adjusted to pass the
> ^^^^^ - based?
>
> > 32-bit time_t to the kernel.
> >
> > We can't directly call __wait4 as it expects a structrusage but we
> ^^^^^^^^^^^^ - struct
> rusage
>
> > have to pass in and use a struct rusage32. The same appies to
> > __getrusage. ---
> > .../linux/generic/wordsize-32/getrusage.c | 39 +++++++++
> > .../linux/generic/wordsize-32/tv32-compat.h | 47 +++++++++++
> > .../sysv/linux/generic/wordsize-32/wait4.c | 79
> > +++++++++++++++++++ 3 files changed, 165 insertions(+)
> > create mode 100644
> > sysdeps/unix/sysv/linux/generic/wordsize-32/getrusage.c create mode
> > 100644 sysdeps/unix/sysv/linux/generic/wordsize-32/wait4.c
> >
> > diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/getrusage.c
> > b/sysdeps/unix/sysv/linux/generic/wordsize-32/getrusage.c new file
> > mode 100644 index 0000000000..2ada94a954
> > --- /dev/null
> > +++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/getrusage.c
> > @@ -0,0 +1,39 @@
> > +/* utimes -- change file timestamps. Linux/RV32/tv32 version.
>
> Please update the in-comment header.
Fixed!
>
> > + Copyright (C) 2020 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 <sys/time.h>
> > +#include <sys/resource.h>
> > +#include <sysdep.h>
> > +#include <tv32-compat.h>
> > +
> > +int
> > +__getrusage (int who, struct rusage *usage)
> > +{
> > +#if __TIMESIZE == 64
> > + struct rusage32 usage32;
> > + if (INLINE_SYSCALL_CALL (getrusage, who, &usage32) == -1)
> > + return -1;
> > +
> > + rusage32_to_rusage64 (&usage32, usage);
> > + return 0;
> > +#else
> > + return INLINE_SYSCALL_CALL (getrusage, who, usage);
> > +#endif
> > +}
>
> This is the same issue as pointed out with __setitimer support.
>
> Following the conversion convention (as in e.g. clock_settime.c) would
> allow Y2038 safe 32 bit ports benefit from this patch.
I commented on the other patch, I'm not clear what you mean here.
>
> > +
> > +strong_alias (__getrusage, getrusage)
> > diff --git
> > a/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h
> > b/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h index
> > aa960a6632..8a4bd15002 100644 ---
> > a/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h +++
> > b/sysdeps/unix/sysv/linux/generic/wordsize-32/tv32-compat.h @@ -24,6
> > +24,7 @@ #include <bits/types.h> #include <bits/types/time_t.h>
> > #include <bits/types/struct_timeval.h>
> > +#include <bits/types/struct_rusage.h>
> >
> > /* Structures containing 'struct timeval' with 32-bit time_t. */
> > struct itimerval32
> > @@ -32,4 +33,50 @@ struct itimerval32
> > struct __timeval_long it_value;
> > };
> >
> > +struct rusage32
>
> struct __rusage32 ?
Good idea, updated
>
> > +{
> > + struct __timeval_long ru_utime; /* user time used */
> > + struct __timeval_long ru_stime; /* system time used */
>
> As pointed out in the other comment - maybe struct
> __timeval32 would be more appropriate?
>
> This is the same convention as we already have with struct
> __timespec64 and __itimerspec64
Yeah, I think you are probably right. I'll wait and see what others
think of the other thread though.
>
> > + long ru_maxrss; /* maximum resident set size */
> > + long ru_ixrss; /* integral shared memory size */
> > + long ru_idrss; /* integral unshared data size */
> > + long ru_isrss; /* integral unshared stack size */
> > + long ru_minflt; /* page reclaims */
> > + long ru_majflt; /* page faults */
> > + long ru_nswap; /* swaps */
> > + long ru_inblock; /* block input operations */
> > + long ru_oublock; /* block output operations */
> > + long ru_msgsnd; /* messages sent */
> > + long ru_msgrcv; /* messages received */
> > + long ru_nsignals; /* signals received */
> > + long ru_nvcsw; /* voluntary context switches */
> > + long ru_nivcsw; /* involuntary " */
> > +};
> > +
> > +static inline void
> > +rusage32_to_rusage64 (const struct rusage32 *restrict r32,
> > + struct rusage *restrict r64)
> > +{
> > + /* Make sure the entire output structure is cleared, including
> > + padding and reserved fields. */
> > + memset (r64, 0, sizeof *r64);
> > +
> > + r64->ru_utime = valid_timeval_long_to_timeval64 (r32->ru_utime);
> > + r64->ru_stime = valid_timeval_long_to_timeval64 (r32->ru_stime);
> > + r64->ru_maxrss = r32->ru_maxrss;
> > + r64->ru_ixrss = r32->ru_ixrss;
> > + r64->ru_idrss = r32->ru_idrss;
> > + r64->ru_isrss = r32->ru_isrss;
> > + r64->ru_minflt = r32->ru_minflt;
> > + r64->ru_majflt = r32->ru_majflt;
> > + r64->ru_nswap = r32->ru_nswap;
> > + r64->ru_inblock = r32->ru_inblock;
> > + r64->ru_oublock = r32->ru_oublock;
> > + r64->ru_msgsnd = r32->ru_msgsnd;
> > + r64->ru_msgrcv = r32->ru_msgrcv;
> > + r64->ru_nsignals = r32->ru_nsignals;
> > + r64->ru_nvcsw = r32->ru_nvcsw;
> > + r64->ru_nivcsw = r32->ru_nivcsw;
> > +}
> > +
> > #endif /* tv32-compat.h */
> > diff --git a/sysdeps/unix/sysv/linux/generic/wordsize-32/wait4.c
> > b/sysdeps/unix/sysv/linux/generic/wordsize-32/wait4.c new file mode
> > 100644 index 0000000000..a4a81a0587
> > --- /dev/null
> > +++ b/sysdeps/unix/sysv/linux/generic/wordsize-32/wait4.c
> > @@ -0,0 +1,79 @@
> > +/* wait4 -- wait for process to change state. Linux/RV32/tv32
> > version.
> > + Copyright (C) 2020 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 <sys/wait.h>
> > +#include <sys/resource.h>
> > +#include <sysdep-cancel.h>
> > +#include <tv32-compat.h>
> > +
> > +pid_t
> > +__wait4 (pid_t pid, int *stat_loc, int options, struct rusage *usage)
> > +{
> > + struct rusage32 usage32;
> > + idtype_t idtype = P_PID;
> > +
> > + if (pid < -1)
> > + {
> > + idtype = P_PGID;
> > + pid *= -1;
> > + }
> > + else if (pid == -1)
> > + idtype = P_ALL;
> > + else if (pid == 0)
> > + idtype = P_PGID;
> > +
> > + options |= WEXITED;
> > +
> > + siginfo_t infop;
> > + if (SYSCALL_CANCEL (waitid, idtype, pid, &infop, options,
> > &usage32) < 0)
> > + return -1;
> > +
> > + if (stat_loc)
> > + {
> > + switch (infop.si_code)
> > + {
> > + case CLD_EXITED:
> > + *stat_loc = W_EXITCODE (infop.si_status, 0);
> > + break;
> > + case CLD_DUMPED:
> > + *stat_loc = WCOREFLAG | infop.si_status;
> > + break;
> > + case CLD_KILLED:
> > + *stat_loc = infop.si_status;
> > + break;
> > + case CLD_TRAPPED:
> > + case CLD_STOPPED:
> > + *stat_loc = W_STOPCODE (infop.si_status);
> > + break;
> > + case CLD_CONTINUED:
> > + *stat_loc = __W_CONTINUED;
> > + break;
> > + default:
> > + *stat_loc = 0;
> > + break;
> > + }
> > + }
> > +
> > + if (usage != NULL)
> > + rusage32_to_rusage64 (&usage32, usage);
> > +
> > + return infop.si_pid;
> > +}
> > +
> > +libc_hidden_def (__wait4);
> > +weak_alias (__wait4, wait4)
>
> This wait4 implementation (as it doesn't use #define __TIMESIZE == 64)
> could be used by all 32 bit ports. Am I right?
Yes, all of these changes apply to all 32-bit ports.
Alistair
>
>
> 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
^ permalink raw reply [flat|nested] 138+ messages in thread
* [RFC v6 06/23] sysdeps: Use long types with 64-bit time_t on 32-bit archs
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (4 preceding siblings ...)
2020-01-12 10:33 ` [RFC v6 05/23] linux: Use 32-bit time_t for rusage Alistair Francis
@ 2020-01-12 10:33 ` Alistair Francis
2020-01-12 21:41 ` Arnd Bergmann
2020-01-12 10:33 ` [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64 Alistair Francis
` (17 subsequent siblings)
23 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:33 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
If we are using a 32-bit architecture with a 64-bit time_t let's
define __SEM_PAD_BEFORE_TIME as 1. This is because the kernel is
expecting a type __kernel_old_time_t which is 32-bit even with a
64-bit time_t. Instead of adding another check, let's just set
__SEM_PAD_BEFORE_TIME as that will use a long type instead of
long long.
---
sysdeps/unix/sysv/linux/bits/sem-pad.h | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/sysdeps/unix/sysv/linux/bits/sem-pad.h b/sysdeps/unix/sysv/linux/bits/sem-pad.h
index 566ce039cc..4b419a6100 100644
--- a/sysdeps/unix/sysv/linux/bits/sem-pad.h
+++ b/sysdeps/unix/sysv/linux/bits/sem-pad.h
@@ -30,4 +30,15 @@
layout conversions for this structure. */
#define __SEM_PAD_AFTER_TIME (__TIMESIZE == 32)
-#define __SEM_PAD_BEFORE_TIME 0
+
+/* If we are using a 32-bit architecture with a 64-bit time_t let's
+ define __SEM_PAD_BEFORE_TIME as 1. This is because the kernel is
+ expecting a type __kernel_old_time_t which is 32-bit even with a
+ 64-bit time_t. Instead of adding another check, let's just set
+ __SEM_PAD_BEFORE_TIME as that will use a long type instead of
+ long long. */
+#if __WORDSIZE == 32 && __TIMESIZE == 64
+# define __SEM_PAD_BEFORE_TIME 1
+#else
+# define __SEM_PAD_BEFORE_TIME 0
+#endif
--
2.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* Re: [RFC v6 06/23] sysdeps: Use long types with 64-bit time_t on 32-bit archs
2020-01-12 10:33 ` [RFC v6 06/23] sysdeps: Use long types with 64-bit time_t on 32-bit archs Alistair Francis
@ 2020-01-12 21:41 ` Arnd Bergmann
2020-01-16 7:30 ` Alistair Francis
0 siblings, 1 reply; 138+ messages in thread
From: Arnd Bergmann @ 2020-01-12 21:41 UTC (permalink / raw)
To: Alistair Francis
Cc: GNU C Library, Adhemerval Zanella, Florian Weimer, Joseph Myers,
palmerdabbelt, macro, Zong Li, Alistair Francis
On Sun, Jan 12, 2020 at 11:40 AM Alistair Francis
<alistair.francis@wdc.com> wrote:
>
> If we are using a 32-bit architecture with a 64-bit time_t let's
> define __SEM_PAD_BEFORE_TIME as 1. This is because the kernel is
> expecting a type __kernel_old_time_t which is 32-bit even with a
> 64-bit time_t. Instead of adding another check, let's just set
> __SEM_PAD_BEFORE_TIME as that will use a long type instead of
> long long.
I think you need to do this differently to avoid truncating the timestamp
to 32 bit. The type in the generic kernel headers for 32-bit targets is not
'__kernel_old_time_t sem_otime; __kernel_long_t pad' but it is
'unsigned long sem_otime; unsigned long sem_otime_high;'.
Both need to be combined to read the 64-bit time_t value. It should
be possible to do this in an architecture independent way, but note
that the two halves are not always adjacent or in the correct order,
and in one case (mips shmbuf) the high word is only 16 bit instead
of 32.
Arnd
> ---
> sysdeps/unix/sysv/linux/bits/sem-pad.h | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/sysdeps/unix/sysv/linux/bits/sem-pad.h b/sysdeps/unix/sysv/linux/bits/sem-pad.h
> index 566ce039cc..4b419a6100 100644
> --- a/sysdeps/unix/sysv/linux/bits/sem-pad.h
> +++ b/sysdeps/unix/sysv/linux/bits/sem-pad.h
> @@ -30,4 +30,15 @@
> layout conversions for this structure. */
>
> #define __SEM_PAD_AFTER_TIME (__TIMESIZE == 32)
> -#define __SEM_PAD_BEFORE_TIME 0
> +
> +/* If we are using a 32-bit architecture with a 64-bit time_t let's
> + define __SEM_PAD_BEFORE_TIME as 1. This is because the kernel is
> + expecting a type __kernel_old_time_t which is 32-bit even with a
> + 64-bit time_t. Instead of adding another check, let's just set
> + __SEM_PAD_BEFORE_TIME as that will use a long type instead of
> + long long. */
> +#if __WORDSIZE == 32 && __TIMESIZE == 64
> +# define __SEM_PAD_BEFORE_TIME 1
> +#else
> +# define __SEM_PAD_BEFORE_TIME 0
> +#endif
> --
> 2.24.1
>
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 06/23] sysdeps: Use long types with 64-bit time_t on 32-bit archs
2020-01-12 21:41 ` Arnd Bergmann
@ 2020-01-16 7:30 ` Alistair Francis
2020-01-16 7:41 ` Alistair Francis
2020-01-16 8:36 ` Arnd Bergmann
0 siblings, 2 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-16 7:30 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alistair Francis, GNU C Library, Adhemerval Zanella,
Florian Weimer, Joseph Myers, Palmer Dabbelt, Maciej W. Rozycki,
Zong Li
On Mon, Jan 13, 2020 at 7:41 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Sun, Jan 12, 2020 at 11:40 AM Alistair Francis
> <alistair.francis@wdc.com> wrote:
> >
> > If we are using a 32-bit architecture with a 64-bit time_t let's
> > define __SEM_PAD_BEFORE_TIME as 1. This is because the kernel is
> > expecting a type __kernel_old_time_t which is 32-bit even with a
> > 64-bit time_t. Instead of adding another check, let's just set
> > __SEM_PAD_BEFORE_TIME as that will use a long type instead of
> > long long.
>
> I think you need to do this differently to avoid truncating the timestamp
> to 32 bit. The type in the generic kernel headers for 32-bit targets is not
> '__kernel_old_time_t sem_otime; __kernel_long_t pad' but it is
> 'unsigned long sem_otime; unsigned long sem_otime_high;'.
Argh! That is even harder.
I think I have updated both sem_otime and sem_ctime to have a high and
low 32-bit version. That looks actually pretty straightforward.
It does seem like we will also have to stich the two values together
as bits/sem.h expects them to just be a time_t. That seems self
contained in sysdeps/unix/sysv/linux/semctl.c though.
>
> Both need to be combined to read the 64-bit time_t value. It should
> be possible to do this in an architecture independent way, but note
> that the two halves are not always adjacent or in the correct order,
> and in one case (mips shmbuf) the high word is only 16 bit instead
> of 32.
That complicates things. I can probably get away with adding a new
define, but that seems like a pain. The best bet looks like allowing
arches to set __SEM_PAD_TIME and then having each arch specify their
own. Maybe with some sane default and then have MIPS set it's own.
Do glibc develepers have a preference here?
Alistair
>
> Arnd
>
> > ---
> > sysdeps/unix/sysv/linux/bits/sem-pad.h | 13 ++++++++++++-
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/sysdeps/unix/sysv/linux/bits/sem-pad.h b/sysdeps/unix/sysv/linux/bits/sem-pad.h
> > index 566ce039cc..4b419a6100 100644
> > --- a/sysdeps/unix/sysv/linux/bits/sem-pad.h
> > +++ b/sysdeps/unix/sysv/linux/bits/sem-pad.h
> > @@ -30,4 +30,15 @@
> > layout conversions for this structure. */
> >
> > #define __SEM_PAD_AFTER_TIME (__TIMESIZE == 32)
> > -#define __SEM_PAD_BEFORE_TIME 0
> > +
> > +/* If we are using a 32-bit architecture with a 64-bit time_t let's
> > + define __SEM_PAD_BEFORE_TIME as 1. This is because the kernel is
> > + expecting a type __kernel_old_time_t which is 32-bit even with a
> > + 64-bit time_t. Instead of adding another check, let's just set
> > + __SEM_PAD_BEFORE_TIME as that will use a long type instead of
> > + long long. */
> > +#if __WORDSIZE == 32 && __TIMESIZE == 64
> > +# define __SEM_PAD_BEFORE_TIME 1
> > +#else
> > +# define __SEM_PAD_BEFORE_TIME 0
> > +#endif
> > --
> > 2.24.1
> >
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 06/23] sysdeps: Use long types with 64-bit time_t on 32-bit archs
2020-01-16 7:30 ` Alistair Francis
@ 2020-01-16 7:41 ` Alistair Francis
2020-01-16 8:36 ` Arnd Bergmann
1 sibling, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-16 7:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alistair Francis, GNU C Library, Adhemerval Zanella,
Florian Weimer, Joseph Myers, Palmer Dabbelt, Maciej W. Rozycki,
Zong Li
On Thu, Jan 16, 2020 at 5:30 PM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Mon, Jan 13, 2020 at 7:41 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Sun, Jan 12, 2020 at 11:40 AM Alistair Francis
> > <alistair.francis@wdc.com> wrote:
> > >
> > > If we are using a 32-bit architecture with a 64-bit time_t let's
> > > define __SEM_PAD_BEFORE_TIME as 1. This is because the kernel is
> > > expecting a type __kernel_old_time_t which is 32-bit even with a
> > > 64-bit time_t. Instead of adding another check, let's just set
> > > __SEM_PAD_BEFORE_TIME as that will use a long type instead of
> > > long long.
> >
> > I think you need to do this differently to avoid truncating the timestamp
> > to 32 bit. The type in the generic kernel headers for 32-bit targets is not
> > '__kernel_old_time_t sem_otime; __kernel_long_t pad' but it is
> > 'unsigned long sem_otime; unsigned long sem_otime_high;'.
>
> Argh! That is even harder.
>
> I think I have updated both sem_otime and sem_ctime to have a high and
> low 32-bit version. That looks actually pretty straightforward.
>
> It does seem like we will also have to stich the two values together
> as bits/sem.h expects them to just be a time_t. That seems self
> contained in sysdeps/unix/sysv/linux/semctl.c though.
Scratch that, sysdeps/unix/sysv/linux/bits/sem.h overwrites it so I
don't see how we could stitch the values together.
>
> >
> > Both need to be combined to read the 64-bit time_t value. It should
> > be possible to do this in an architecture independent way, but note
> > that the two halves are not always adjacent or in the correct order,
> > and in one case (mips shmbuf) the high word is only 16 bit instead
> > of 32.
>
> That complicates things. I can probably get away with adding a new
> define, but that seems like a pain. The best bet looks like allowing
> arches to set __SEM_PAD_TIME and then having each arch specify their
> own. Maybe with some sane default and then have MIPS set it's own.
This actually isn't bad, I just added this:
#define __SEM_NO_PAD (__WORDSIZE == 32 && __TIMESIZE == 64)
and forced it to 0 for MIPS.
Alistair
>
> Do glibc develepers have a preference here?
>
> Alistair
>
> >
> > Arnd
> >
> > > ---
> > > sysdeps/unix/sysv/linux/bits/sem-pad.h | 13 ++++++++++++-
> > > 1 file changed, 12 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/sysdeps/unix/sysv/linux/bits/sem-pad.h b/sysdeps/unix/sysv/linux/bits/sem-pad.h
> > > index 566ce039cc..4b419a6100 100644
> > > --- a/sysdeps/unix/sysv/linux/bits/sem-pad.h
> > > +++ b/sysdeps/unix/sysv/linux/bits/sem-pad.h
> > > @@ -30,4 +30,15 @@
> > > layout conversions for this structure. */
> > >
> > > #define __SEM_PAD_AFTER_TIME (__TIMESIZE == 32)
> > > -#define __SEM_PAD_BEFORE_TIME 0
> > > +
> > > +/* If we are using a 32-bit architecture with a 64-bit time_t let's
> > > + define __SEM_PAD_BEFORE_TIME as 1. This is because the kernel is
> > > + expecting a type __kernel_old_time_t which is 32-bit even with a
> > > + 64-bit time_t. Instead of adding another check, let's just set
> > > + __SEM_PAD_BEFORE_TIME as that will use a long type instead of
> > > + long long. */
> > > +#if __WORDSIZE == 32 && __TIMESIZE == 64
> > > +# define __SEM_PAD_BEFORE_TIME 1
> > > +#else
> > > +# define __SEM_PAD_BEFORE_TIME 0
> > > +#endif
> > > --
> > > 2.24.1
> > >
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 06/23] sysdeps: Use long types with 64-bit time_t on 32-bit archs
2020-01-16 7:30 ` Alistair Francis
2020-01-16 7:41 ` Alistair Francis
@ 2020-01-16 8:36 ` Arnd Bergmann
2020-01-16 22:16 ` Alistair Francis
1 sibling, 1 reply; 138+ messages in thread
From: Arnd Bergmann @ 2020-01-16 8:36 UTC (permalink / raw)
To: Alistair Francis
Cc: Alistair Francis, GNU C Library, Adhemerval Zanella,
Florian Weimer, Joseph Myers, Palmer Dabbelt, Maciej W. Rozycki,
Zong Li
On Thu, Jan 16, 2020 at 8:31 AM Alistair Francis <alistair23@gmail.com> wrote:
> On Mon, Jan 13, 2020 at 7:41 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Sun, Jan 12, 2020 at 11:40 AM Alistair Francis <alistair.francis@wdc.com> wrote:
> > >
> > > If we are using a 32-bit architecture with a 64-bit time_t let's
> > > define __SEM_PAD_BEFORE_TIME as 1. This is because the kernel is
> > > expecting a type __kernel_old_time_t which is 32-bit even with a
> > > 64-bit time_t. Instead of adding another check, let's just set
> > > __SEM_PAD_BEFORE_TIME as that will use a long type instead of
> > > long long.
> >
> > I think you need to do this differently to avoid truncating the timestamp
> > to 32 bit. The type in the generic kernel headers for 32-bit targets is not
> > '__kernel_old_time_t sem_otime; __kernel_long_t pad' but it is
> > 'unsigned long sem_otime; unsigned long sem_otime_high;'.
>
> Argh! That is even harder.
>
> I think I have updated both sem_otime and sem_ctime to have a high and
> low 32-bit version. That looks actually pretty straightforward.
>
> It does seem like we will also have to stich the two values together
> as bits/sem.h expects them to just be a time_t. That seems self
> contained in sysdeps/unix/sysv/linux/semctl.c though.
>
> >
> > Both need to be combined to read the 64-bit time_t value. It should
> > be possible to do this in an architecture independent way, but note
> > that the two halves are not always adjacent or in the correct order,
> > and in one case (mips shmbuf) the high word is only 16 bit instead
> > of 32.
>
> That complicates things. I can probably get away with adding a new
> define, but that seems like a pain. The best bet looks like allowing
> arches to set __SEM_PAD_TIME and then having each arch specify their
> own. Maybe with some sane default and then have MIPS set it's own.
There are three approaches that we have discussed in the past:
1. Convert the timestamps in place where possible, with special cases
for architectures that have the upper halves in non-consecutive
locations
2. Create a new set of portable sysvipc data structures for time64
user space, e.g. modeled after the generic 64-bit structures,
and convert all fields between the kernel version and the libc
version.
3. Keep the current layout but rename the existing time fields and
add new 64-bit fields at the end.
You can have a look at the musl implementation for the third approach,
the main advantage there is that it simplifies conversion between
the old and new format for supporting the time32 interfaces on
the existing 32-bit architectures as wrappers on top of the tim64
interfaces.
There is also a simplified form of 1) that will work on most of the
architectures that glibc cares about: i386, armel, rv32le, csky, nds32,
ppc32, microblaze-le, sparc, parisc, sh-le and nios2 all have the 'high'
fields in the right place so you can simply treat them as 64-bit
fields with no padding, while armeb, mips (all of them), s390,
microblaze-be, sh-be and m68k get it wrong in one way or another
and require would require some special case here.
Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 06/23] sysdeps: Use long types with 64-bit time_t on 32-bit archs
2020-01-16 8:36 ` Arnd Bergmann
@ 2020-01-16 22:16 ` Alistair Francis
2020-01-16 22:41 ` Joseph Myers
0 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-01-16 22:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alistair Francis, GNU C Library, Adhemerval Zanella,
Florian Weimer, Joseph Myers, Palmer Dabbelt, Maciej W. Rozycki,
Zong Li
On Thu, Jan 16, 2020 at 6:36 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Jan 16, 2020 at 8:31 AM Alistair Francis <alistair23@gmail.com> wrote:
> > On Mon, Jan 13, 2020 at 7:41 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Sun, Jan 12, 2020 at 11:40 AM Alistair Francis <alistair.francis@wdc.com> wrote:
> > > >
> > > > If we are using a 32-bit architecture with a 64-bit time_t let's
> > > > define __SEM_PAD_BEFORE_TIME as 1. This is because the kernel is
> > > > expecting a type __kernel_old_time_t which is 32-bit even with a
> > > > 64-bit time_t. Instead of adding another check, let's just set
> > > > __SEM_PAD_BEFORE_TIME as that will use a long type instead of
> > > > long long.
> > >
> > > I think you need to do this differently to avoid truncating the timestamp
> > > to 32 bit. The type in the generic kernel headers for 32-bit targets is not
> > > '__kernel_old_time_t sem_otime; __kernel_long_t pad' but it is
> > > 'unsigned long sem_otime; unsigned long sem_otime_high;'.
> >
> > Argh! That is even harder.
> >
> > I think I have updated both sem_otime and sem_ctime to have a high and
> > low 32-bit version. That looks actually pretty straightforward.
> >
> > It does seem like we will also have to stich the two values together
> > as bits/sem.h expects them to just be a time_t. That seems self
> > contained in sysdeps/unix/sysv/linux/semctl.c though.
> >
> > >
> > > Both need to be combined to read the 64-bit time_t value. It should
> > > be possible to do this in an architecture independent way, but note
> > > that the two halves are not always adjacent or in the correct order,
> > > and in one case (mips shmbuf) the high word is only 16 bit instead
> > > of 32.
> >
> > That complicates things. I can probably get away with adding a new
> > define, but that seems like a pain. The best bet looks like allowing
> > arches to set __SEM_PAD_TIME and then having each arch specify their
> > own. Maybe with some sane default and then have MIPS set it's own.
>
> There are three approaches that we have discussed in the past:
>
> 1. Convert the timestamps in place where possible, with special cases
> for architectures that have the upper halves in non-consecutive
> locations
> 2. Create a new set of portable sysvipc data structures for time64
> user space, e.g. modeled after the generic 64-bit structures,
> and convert all fields between the kernel version and the libc
> version.
> 3. Keep the current layout but rename the existing time fields and
> add new 64-bit fields at the end.
Ah ok, I prefer option 1 I think.
So I guess we will do something like:
1. Define __semid_ds32 in sysdeps/unix/sysv/linux/bits/sem.h based on
macros in sem-pad.h
- This allows us to have a generic implementation in
sysdeps/unix/sysv/linux/bits that can be overwritten by other
architectures
2. If 32-bit with 64-bit time_t pass __semid_ds32 into the kernel in
sysdeps/unix/sysv/linux/semctl.c
- Then reconstruct the user exposed version (unchanged). This is
the current struct semid_ds and uses time_t
- The problem is not every architecture uses time_t here, that
only seems to apply if __TIMESIZE == 32 so we should be ok here.
Alistair
>
> You can have a look at the musl implementation for the third approach,
> the main advantage there is that it simplifies conversion between
> the old and new format for supporting the time32 interfaces on
> the existing 32-bit architectures as wrappers on top of the tim64
> interfaces.
>
> There is also a simplified form of 1) that will work on most of the
> architectures that glibc cares about: i386, armel, rv32le, csky, nds32,
> ppc32, microblaze-le, sparc, parisc, sh-le and nios2 all have the 'high'
> fields in the right place so you can simply treat them as 64-bit
> fields with no padding, while armeb, mips (all of them), s390,
> microblaze-be, sh-be and m68k get it wrong in one way or another
> and require would require some special case here.
>
> Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 06/23] sysdeps: Use long types with 64-bit time_t on 32-bit archs
2020-01-16 22:16 ` Alistair Francis
@ 2020-01-16 22:41 ` Joseph Myers
0 siblings, 0 replies; 138+ messages in thread
From: Joseph Myers @ 2020-01-16 22:41 UTC (permalink / raw)
To: Alistair Francis
Cc: Arnd Bergmann, Alistair Francis, GNU C Library,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Fri, 17 Jan 2020, Alistair Francis wrote:
> 1. Define __semid_ds32 in sysdeps/unix/sysv/linux/bits/sem.h based on
> macros in sem-pad.h
The usual rule applies that internal structures generally do not belong in
installed headers.
sysdeps/unix/sysv/linux/bits/sem.h should define the *public* struct
semid_ds. That public definition may eventually vary based on some #if
conditions (__USE_TIME_BITS64 or whatever _TIME_BITS=64 causes to be
defined - not yet, only once we're actually ready to support _TIME_BITS=64
as a complete, consistent interface). But if the purpose of a definition
is to pass into the kernel, rather than as a public API (under a public
name) for user programs, it does not belong in an installed header -
unless it's e.g. referenced in some other public structure in some way.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (5 preceding siblings ...)
2020-01-12 10:33 ` [RFC v6 06/23] sysdeps: Use long types with 64-bit time_t on 32-bit archs Alistair Francis
@ 2020-01-12 10:33 ` Alistair Francis
2020-01-14 12:07 ` Lukasz Majewski
` (2 more replies)
2020-01-12 10:33 ` [RFC v6 08/23] RISC-V: Define __NR_* as __NR_*_time64/64 for 32-bit Alistair Francis
` (16 subsequent siblings)
23 siblings, 3 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:33 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
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.
For the typesizes.h, here are justifications for the changes from the
generic version (based on Arnd's very helpful feedback):
- All the !__USE_FILE_OFFSET64 types (__off_t, __ino_t, __rlim_t, ...) are
changed to match the 64-bit replacements.
- __time_t is defined to 64 bit, but no __time64_t is added. This makes sense
as we don't have the time64 support for other 32-bit architectures yet, and
it will be easy to change when that happens.
- __suseconds_t is 64-bit. This matches what we use the kerne ABI for the
few drivers that are relying on 'struct timeval' input arguments in
ioctl, as well as the adjtimex system call. It means that timeval has to
be defined without the padding, unlike timespec, which needs padding.
---
.../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 | 90 +++++++++++++++++++
sysdeps/unix/sysv/linux/riscv/kernel_stat.h | 23 +++++
5 files changed, 256 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
create mode 100644 sysdeps/unix/sysv/linux/riscv/kernel_stat.h
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..8d401d1976
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/bits/environments.h
@@ -0,0 +1,85 @@
+/* Copyright (C) 1999-2020 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..cc21b45ef1
--- /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-2020 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..afb5d86b2b
--- /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-2020 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..0da3bdeb5d
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
@@ -0,0 +1,90 @@
+/* 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 __U32_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 __SWORD_TYPE
+#define __ID_T_TYPE __U32_TYPE
+#define __CLOCK_T_TYPE __SLONGWORD_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 __S32_TYPE
+#define __FSID_T_TYPE struct { int __val[2]; }
+#define __SSIZE_T_TYPE __SWORD_TYPE
+#define __SYSCALL_SLONG_TYPE __SLONGWORD_TYPE
+#define __SYSCALL_ULONG_TYPE __ULONGWORD_TYPE
+#define __CPU_MASK_TYPE __ULONGWORD_TYPE
+
+/* 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
+
+/* And for fsblkcnt_t and fsfilcnt_t */
+# define __STATFS_MATCHES_STATFS64 1
+
+/* And for fsblkcnt_t, fsblkcnt64_t, fsfilcnt_t and fsfilcnt64_t. */
+# define __STATFS_MATCHES_STATFS64 1
+
+/* Define these as RV32 requires 64-bit syscall. */
+#if __riscv_xlen == 32
+#define __ASSUME_TIME64_SYSCALLS 1
+#define __ASSUME_RLIM64_SYSCALLS 1
+#endif
+
+/* Number of descriptors that can fit in an `fd_set'. */
+#define __FD_SETSIZE 1024
+
+
+#endif /* bits/typesizes.h */
diff --git a/sysdeps/unix/sysv/linux/riscv/kernel_stat.h b/sysdeps/unix/sysv/linux/riscv/kernel_stat.h
new file mode 100644
index 0000000000..2c026f1b9c
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/kernel_stat.h
@@ -0,0 +1,23 @@
+/* Copyright (C) 2011-2020 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>
+
+#define STAT_IS_KERNEL_STAT 1
+
+#define XSTAT_IS_XSTAT64 1
+#define STATFS_IS_STATFS64 0
--
2.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-01-12 10:33 ` [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64 Alistair Francis
@ 2020-01-14 12:07 ` Lukasz Majewski
2020-01-15 5:09 ` Alistair Francis
2020-02-12 0:14 ` Vineet Gupta
2020-02-19 0:56 ` Vineet Gupta
2 siblings, 1 reply; 138+ messages in thread
From: Lukasz Majewski @ 2020-01-14 12:07 UTC (permalink / raw)
To: Alistair Francis
Cc: libc-alpha, arnd, adhemerval.zanella, fweimer, joseph,
palmerdabbelt, macro, zongbox, alistair23
[-- Attachment #1: Type: text/plain, Size: 13911 bytes --]
Hi Alistair,
> 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.
>
> For the typesizes.h, here are justifications for the changes from the
> generic version (based on Arnd's very helpful feedback):
> - All the !__USE_FILE_OFFSET64 types (__off_t, __ino_t, __rlim_t,
> ...) are changed to match the 64-bit replacements.
>
> - __time_t is defined to 64 bit, but no __time64_t is added. This
> makes sense as we don't have the time64 support for other 32-bit
> architectures yet, and it will be easy to change when that happens.
>
> - __suseconds_t is 64-bit. This matches what we use the kerne ABI for
^^^^^ kernel
> the few drivers that are relying on 'struct timeval' input arguments
> in ioctl, as well as the adjtimex system call. It means that timeval
> has to be defined without the padding, unlike timespec, which needs
> padding. ---
> .../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 | 90
> +++++++++++++++++++ sysdeps/unix/sysv/linux/riscv/kernel_stat.h |
> 23 +++++ 5 files changed, 256 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
> create mode 100644 sysdeps/unix/sysv/linux/riscv/kernel_stat.h
>
> 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..8d401d1976
> --- /dev/null
> +++ b/sysdeps/unix/sysv/linux/riscv/bits/environments.h
> @@ -0,0 +1,85 @@
> +/* Copyright (C) 1999-2020 Free Software Foundation, Inc.
> + This file is part of the GNU C Library.
2020
> +
> + 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..cc21b45ef1
> --- /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-2020 Free Software Foundation, Inc.
> + This file is part of the GNU C Library.
2020 ?
> +
> + 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..afb5d86b2b
> --- /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-2020 Free Software Foundation, Inc.
> + This file is part of the GNU C Library.
> +
2020
> + 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
Ok.
> 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..0da3bdeb5d
> --- /dev/null
> +++ b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
> @@ -0,0 +1,90 @@
> +/* 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 __U32_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 __SWORD_TYPE
> +#define __ID_T_TYPE __U32_TYPE
> +#define __CLOCK_T_TYPE __SLONGWORD_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 __S32_TYPE
> +#define __FSID_T_TYPE struct { int __val[2]; }
> +#define __SSIZE_T_TYPE __SWORD_TYPE
> +#define __SYSCALL_SLONG_TYPE __SLONGWORD_TYPE
> +#define __SYSCALL_ULONG_TYPE __ULONGWORD_TYPE
> +#define __CPU_MASK_TYPE __ULONGWORD_TYPE
> +
> +/* 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
> +
> +/* And for fsblkcnt_t and fsfilcnt_t */
> +# define __STATFS_MATCHES_STATFS64 1
> +
> +/* And for fsblkcnt_t, fsblkcnt64_t, fsfilcnt_t and fsfilcnt64_t. */
> +# define __STATFS_MATCHES_STATFS64 1
> +
> +/* Define these as RV32 requires 64-bit syscall. */
> +#if __riscv_xlen == 32
> +#define __ASSUME_TIME64_SYSCALLS 1
> +#define __ASSUME_RLIM64_SYSCALLS 1
> +#endif
> +
> +/* Number of descriptors that can fit in an `fd_set'. */
> +#define __FD_SETSIZE 1024
> +
> +
> +#endif /* bits/typesizes.h */
> diff --git a/sysdeps/unix/sysv/linux/riscv/kernel_stat.h
> b/sysdeps/unix/sysv/linux/riscv/kernel_stat.h new file mode 100644
> index 0000000000..2c026f1b9c
> --- /dev/null
> +++ b/sysdeps/unix/sysv/linux/riscv/kernel_stat.h
> @@ -0,0 +1,23 @@
> +/* Copyright (C) 2011-2020 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>
> +
> +#define STAT_IS_KERNEL_STAT 1
> +
> +#define XSTAT_IS_XSTAT64 1
> +#define STATFS_IS_STATFS64 0
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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-01-14 12:07 ` Lukasz Majewski
@ 2020-01-15 5:09 ` Alistair Francis
0 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-15 5:09 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Joseph Myers, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Tue, Jan 14, 2020 at 10:07 PM Lukasz Majewski <lukma@denx.de> wrote:
>
> Hi Alistair,
>
> > 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.
> >
> > For the typesizes.h, here are justifications for the changes from the
> > generic version (based on Arnd's very helpful feedback):
> > - All the !__USE_FILE_OFFSET64 types (__off_t, __ino_t, __rlim_t,
> > ...) are changed to match the 64-bit replacements.
> >
> > - __time_t is defined to 64 bit, but no __time64_t is added. This
> > makes sense as we don't have the time64 support for other 32-bit
> > architectures yet, and it will be easy to change when that happens.
> >
> > - __suseconds_t is 64-bit. This matches what we use the kerne ABI for
>
> ^^^^^ kernel
Fixed
>
> > the few drivers that are relying on 'struct timeval' input arguments
> > in ioctl, as well as the adjtimex system call. It means that timeval
> > has to be defined without the padding, unlike timespec, which needs
> > padding. ---
> > .../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 | 90
> > +++++++++++++++++++ sysdeps/unix/sysv/linux/riscv/kernel_stat.h |
> > 23 +++++ 5 files changed, 256 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
> > create mode 100644 sysdeps/unix/sysv/linux/riscv/kernel_stat.h
> >
> > 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..8d401d1976
> > --- /dev/null
> > +++ b/sysdeps/unix/sysv/linux/riscv/bits/environments.h
> > @@ -0,0 +1,85 @@
> > +/* Copyright (C) 1999-2020 Free Software Foundation, Inc.
> > + This file is part of the GNU C Library.
>
> 2020
>
> > +
> > + 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..cc21b45ef1
> > --- /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-2020 Free Software Foundation, Inc.
> > + This file is part of the GNU C Library.
>
> 2020 ?
>
> > +
> > + 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..afb5d86b2b
> > --- /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-2020 Free Software Foundation, Inc.
> > + This file is part of the GNU C Library.
> > +
>
> 2020
I have updated them all to "2019-2020" as I wrote it in 2019 and all
the other glibc files seem to have a range for the copyright.
Alistair
>
> > + 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
>
> Ok.
>
> > 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..0da3bdeb5d
> > --- /dev/null
> > +++ b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
> > @@ -0,0 +1,90 @@
> > +/* 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 __U32_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 __SWORD_TYPE
> > +#define __ID_T_TYPE __U32_TYPE
> > +#define __CLOCK_T_TYPE __SLONGWORD_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 __S32_TYPE
> > +#define __FSID_T_TYPE struct { int __val[2]; }
> > +#define __SSIZE_T_TYPE __SWORD_TYPE
> > +#define __SYSCALL_SLONG_TYPE __SLONGWORD_TYPE
> > +#define __SYSCALL_ULONG_TYPE __ULONGWORD_TYPE
> > +#define __CPU_MASK_TYPE __ULONGWORD_TYPE
> > +
> > +/* 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
> > +
> > +/* And for fsblkcnt_t and fsfilcnt_t */
> > +# define __STATFS_MATCHES_STATFS64 1
> > +
> > +/* And for fsblkcnt_t, fsblkcnt64_t, fsfilcnt_t and fsfilcnt64_t. */
> > +# define __STATFS_MATCHES_STATFS64 1
> > +
> > +/* Define these as RV32 requires 64-bit syscall. */
> > +#if __riscv_xlen == 32
> > +#define __ASSUME_TIME64_SYSCALLS 1
> > +#define __ASSUME_RLIM64_SYSCALLS 1
> > +#endif
> > +
> > +/* Number of descriptors that can fit in an `fd_set'. */
> > +#define __FD_SETSIZE 1024
> > +
> > +
> > +#endif /* bits/typesizes.h */
> > diff --git a/sysdeps/unix/sysv/linux/riscv/kernel_stat.h
> > b/sysdeps/unix/sysv/linux/riscv/kernel_stat.h new file mode 100644
> > index 0000000000..2c026f1b9c
> > --- /dev/null
> > +++ b/sysdeps/unix/sysv/linux/riscv/kernel_stat.h
> > @@ -0,0 +1,23 @@
> > +/* Copyright (C) 2011-2020 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>
> > +
> > +#define STAT_IS_KERNEL_STAT 1
> > +
> > +#define XSTAT_IS_XSTAT64 1
> > +#define STATFS_IS_STATFS64 0
>
>
>
>
> 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
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-01-12 10:33 ` [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64 Alistair Francis
2020-01-14 12:07 ` Lukasz Majewski
@ 2020-02-12 0:14 ` Vineet Gupta
2020-02-12 0:14 ` Alistair Francis
2020-02-19 0:56 ` Vineet Gupta
2 siblings, 1 reply; 138+ messages in thread
From: Vineet Gupta @ 2020-02-12 0:14 UTC (permalink / raw)
To: Alistair Francis, libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair23, arcml
Hi Alistair,
On 1/12/20 2:33 AM, Alistair Francis wrote:
> 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.
>
> For the typesizes.h, here are justifications for the changes from the
> generic version (based on Arnd's very helpful feedback):
> - All the !__USE_FILE_OFFSET64 types (__off_t, __ino_t, __rlim_t, ...) are
> changed to match the 64-bit replacements.
>
> - __time_t is defined to 64 bit, but no __time64_t is added. This makes sense
> as we don't have the time64 support for other 32-bit architectures yet, and
> it will be easy to change when that happens.
>
> - __suseconds_t is 64-bit. This matches what we use the kerne ABI for the
> few drivers that are relying on 'struct timeval' input arguments in
> ioctl, as well as the adjtimex system call. It means that timeval has to
> be defined without the padding, unlike timespec, which needs padding.
> ---
> .../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 | 90 +++++++++++++++++++
> sysdeps/unix/sysv/linux/riscv/kernel_stat.h | 23 +++++
> 5 files changed, 256 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
> create mode 100644 sysdeps/unix/sysv/linux/riscv/kernel_stat.h
>
> 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..8d401d1976
> --- /dev/null
> +++ b/sysdeps/unix/sysv/linux/riscv/bits/environments.h
> @@ -0,0 +1,85 @@
> +/* Copyright (C) 1999-2020 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..cc21b45ef1
> --- /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-2020 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..afb5d86b2b
> --- /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-2020 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..0da3bdeb5d
> --- /dev/null
> +++ b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
I was hoping newer arches could simply use the asm-generic one ?
> +/* 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
This is orthogonal to time_t but since we are on topic of newer ports, how are you
doing this. The asm-generic uapi defines
typedef __kernel_long_t __kernel_off_t;
and types.h defines
typedef __kernel_off_t off_t;
And I presume long on RV32 is 32-bits
> +
> +/* 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
> +
> +/* And for fsblkcnt_t and fsfilcnt_t */
> +# define __STATFS_MATCHES_STATFS64 1
> +
> +/* And for fsblkcnt_t, fsblkcnt64_t, fsfilcnt_t and fsfilcnt64_t. */
> +# define __STATFS_MATCHES_STATFS64 1
> +
> +/* Define these as RV32 requires 64-bit syscall. */
> +#if __riscv_xlen == 32
> +#define __ASSUME_TIME64_SYSCALLS 1
From the POV of newer arches needing 64-bit time_t support, this need not be
forced as it is set automatically for kernel >= 5.1
> +#define __ASSUME_RLIM64_SYSCALLS 1
Is this used anywhere ?
Thx,
-Vineet
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-02-12 0:14 ` Vineet Gupta
@ 2020-02-12 0:14 ` Alistair Francis
2020-02-12 1:30 ` Joseph Myers
2020-02-12 1:42 ` [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64 Vineet Gupta
0 siblings, 2 replies; 138+ messages in thread
From: Alistair Francis @ 2020-02-12 0:14 UTC (permalink / raw)
To: Vineet Gupta
Cc: Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Joseph Myers, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li, arcml
On Tue, Feb 11, 2020 at 4:14 PM Vineet Gupta <vineetg76@gmail.com> wrote:
>
> Hi Alistair,
Hi Vineet,
>
> On 1/12/20 2:33 AM, Alistair Francis wrote:
> > 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.
> >
> > For the typesizes.h, here are justifications for the changes from the
> > generic version (based on Arnd's very helpful feedback):
> > - All the !__USE_FILE_OFFSET64 types (__off_t, __ino_t, __rlim_t, ...) are
> > changed to match the 64-bit replacements.
> >
> > - __time_t is defined to 64 bit, but no __time64_t is added. This makes sense
> > as we don't have the time64 support for other 32-bit architectures yet, and
> > it will be easy to change when that happens.
> >
> > - __suseconds_t is 64-bit. This matches what we use the kerne ABI for the
> > few drivers that are relying on 'struct timeval' input arguments in
> > ioctl, as well as the adjtimex system call. It means that timeval has to
> > be defined without the padding, unlike timespec, which needs padding.
> > ---
> > .../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 | 90 +++++++++++++++++++
> > sysdeps/unix/sysv/linux/riscv/kernel_stat.h | 23 +++++
> > 5 files changed, 256 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
> > create mode 100644 sysdeps/unix/sysv/linux/riscv/kernel_stat.h
> >
> > 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..8d401d1976
> > --- /dev/null
> > +++ b/sysdeps/unix/sysv/linux/riscv/bits/environments.h
> > @@ -0,0 +1,85 @@
> > +/* Copyright (C) 1999-2020 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..cc21b45ef1
> > --- /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-2020 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..afb5d86b2b
> > --- /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-2020 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..0da3bdeb5d
> > --- /dev/null
> > +++ b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
>
> I was hoping newer arches could simply use the asm-generic one ?
We need to specify that RV32 uses a 64-bit time_t. The generic ones
don't do that for 32-bit arches.
>
> > +/* 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
>
> This is orthogonal to time_t but since we are on topic of newer ports, how are you
> doing this. The asm-generic uapi defines
>
> typedef __kernel_long_t __kernel_off_t;
>
> and types.h defines
>
> typedef __kernel_off_t off_t;
>
> And I presume long on RV32 is 32-bits
Can you point me to the code? Last time I looked the kernel used the
64-bit versions for the syscalls on RV32.
>
> > +
> > +/* 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
> > +
> > +/* And for fsblkcnt_t and fsfilcnt_t */
> > +# define __STATFS_MATCHES_STATFS64 1
> > +
> > +/* And for fsblkcnt_t, fsblkcnt64_t, fsfilcnt_t and fsfilcnt64_t. */
> > +# define __STATFS_MATCHES_STATFS64 1
> > +
> > +/* Define these as RV32 requires 64-bit syscall. */
> > +#if __riscv_xlen == 32
> > +#define __ASSUME_TIME64_SYSCALLS 1
>
> From the POV of newer arches needing 64-bit time_t support, this need not be
> forced as it is set automatically for kernel >= 5.1
Ah, I think you are right about this and we don't need to define it.
>
> > +#define __ASSUME_RLIM64_SYSCALLS 1
>
> Is this used anywhere ?
Apparently not, I have removed it.
Alistair
>
> Thx,
> -Vineet
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-02-12 0:14 ` Alistair Francis
@ 2020-02-12 1:30 ` Joseph Myers
2020-02-14 22:39 ` Alistair Francis
2020-02-12 1:42 ` [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64 Vineet Gupta
1 sibling, 1 reply; 138+ messages in thread
From: Joseph Myers @ 2020-02-12 1:30 UTC (permalink / raw)
To: Alistair Francis
Cc: Vineet Gupta, Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li, arcml
On Tue, 11 Feb 2020, Alistair Francis wrote:
> > > 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..0da3bdeb5d
> > > --- /dev/null
> > > +++ b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
> >
> > I was hoping newer arches could simply use the asm-generic one ?
>
> We need to specify that RV32 uses a 64-bit time_t. The generic ones
> don't do that for 32-bit arches.
Since it seems we'd like future 32-bit ports of glibc to use 64-bit time
and offsets, we should make that as easy as possible.
That is, you need an RISC-V-specific bits/timesize.h. But you shouldn't
need an RISC-V-specific bits/typesizes.h - rather, make the linux/generic
one do the right thing for __TIME_T_TYPE based on bits/timesize.h. And
have some other header that 32-bit linux/generic ports can use to say
whether they use the 64-bit offset/stat/statfs interface, that
bits/typesizes.h can use together with its existing __LP64__ check, and
make the definitions of __OFF_T_TYPE etc. check that as well, and then you
shouldn't need an RISC-V-specific bits/typesizes.h - the RISC-V-specific
headers should be strictly minimal. (No architecture-specific
bits/time64.h headers should be needed in any case.)
At some point (or indeed now) we might flip the default for linux/generic
so the architectures needing an architecture-specific header are only the
older 32-bit linux/generic architectures that have support for 32-bit
times and offsets, and the newer ones with no such support don't need such
a header.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-02-12 1:30 ` Joseph Myers
@ 2020-02-14 22:39 ` Alistair Francis
2020-02-18 23:05 ` switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64) Vineet Gupta
0 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-02-14 22:39 UTC (permalink / raw)
To: Joseph Myers
Cc: Vineet Gupta, Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li, arcml
On Tue, Feb 11, 2020 at 5:30 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Tue, 11 Feb 2020, Alistair Francis wrote:
>
> > > > 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..0da3bdeb5d
> > > > --- /dev/null
> > > > +++ b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
> > >
> > > I was hoping newer arches could simply use the asm-generic one ?
> >
> > We need to specify that RV32 uses a 64-bit time_t. The generic ones
> > don't do that for 32-bit arches.
>
> Since it seems we'd like future 32-bit ports of glibc to use 64-bit time
> and offsets, we should make that as easy as possible.
>
> That is, you need an RISC-V-specific bits/timesize.h. But you shouldn't
> need an RISC-V-specific bits/typesizes.h - rather, make the linux/generic
> one do the right thing for __TIME_T_TYPE based on bits/timesize.h. And
> have some other header that 32-bit linux/generic ports can use to say
> whether they use the 64-bit offset/stat/statfs interface, that
> bits/typesizes.h can use together with its existing __LP64__ check, and
> make the definitions of __OFF_T_TYPE etc. check that as well, and then you
> shouldn't need an RISC-V-specific bits/typesizes.h - the RISC-V-specific
> headers should be strictly minimal. (No architecture-specific
> bits/time64.h headers should be needed in any case.)
Ok, I have updated this. I'll send the patch once my "Always use
32-bit time_t for certain syscalls" series is in (the headers are
changed in that series).
Alistair
>
> At some point (or indeed now) we might flip the default for linux/generic
> so the architectures needing an architecture-specific header are only the
> older 32-bit linux/generic architectures that have support for 32-bit
> times and offsets, and the newer ones with no such support don't need such
> a header.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-14 22:39 ` Alistair Francis
@ 2020-02-18 23:05 ` Vineet Gupta
2020-02-18 23:13 ` Joseph Myers
2020-02-19 23:11 ` Lukasz Majewski
0 siblings, 2 replies; 138+ messages in thread
From: Vineet Gupta @ 2020-02-18 23:05 UTC (permalink / raw)
To: Alistair Francis, Joseph Myers
Cc: Florian Weimer, GNU C Library, Arnd Bergmann, Palmer Dabbelt,
Zong Li, Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
arcml
Hi Alistair, Arnd
On 2/14/20 2:39 PM, Alistair Francis wrote:
> On Tue, Feb 11, 2020 at 5:30 PM Joseph Myers <joseph@codesourcery.com> wrote:
>> On Tue, 11 Feb 2020, Alistair Francis wrote:
>>
>>>>> 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..0da3bdeb5d
>>>>> --- /dev/null
>>>>> +++ b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
>>>> I was hoping newer arches could simply use the asm-generic one ?
>>> We need to specify that RV32 uses a 64-bit time_t. The generic ones
>>> don't do that for 32-bit arches.
>> Since it seems we'd like future 32-bit ports of glibc to use 64-bit time
>> and offsets, we should make that as easy as possible.
>>
>> That is, you need an RISC-V-specific bits/timesize.h. But you shouldn't
>> need an RISC-V-specific bits/typesizes.h - rather, make the linux/generic
>> one do the right thing for __TIME_T_TYPE based on bits/timesize.h. And
>> have some other header that 32-bit linux/generic ports can use to say
>> whether they use the 64-bit offset/stat/statfs interface, that
>> bits/typesizes.h can use together with its existing __LP64__ check, and
>> make the definitions of __OFF_T_TYPE etc. check that as well, and then you
>> shouldn't need an RISC-V-specific bits/typesizes.h - the RISC-V-specific
>> headers should be strictly minimal. (No architecture-specific
>> bits/time64.h headers should be needed in any case.)
> Ok, I have updated this. I'll send the patch once my "Always use
> 32-bit time_t for certain syscalls" series is in (the headers are
> changed in that series).
I guess you haven't pushed changes yet, which don't make full copy of typesizes.h ?
Anyhow I have a version based on your prior next branch where I switched ARC to
64-bit time_t - things work fine in general but I see some additional failures
with the testsuite.
Consider io/test-stat2.c which calls stat() and stat64() and compares the results:
it now fails for ctime mismatch
| ...
| st_atime: [72] 644245094405576070 vs [72] 644245094405576070 OK
| st_mtime: [88] 1975684956160000000 vs [88] 1975684956160000000 OK
| st_ctime: [104] 0 vs [104] 2306351876938924035 FAIL
In kernel asm-generic stat64 has 32-bit ctime (secs)
struct stat64 {
...
int st_atime; <-- offset 72
unsigned int st_atime_nsec;
int st_mtime; <-- offset *80*
unsigned int st_mtime_nsec;
int st_ctime; <-- offset 92
unsigned int st_ctime_nsec;
...
};
In glibc, we have 64-bit time_t based timestamps so the structure diverges with
kernel counterpart from time fields onwards.
__extension__ typedef __int64_t __time_t; <-- ARC switched to 64-bit time_t
struct timespec
{
__time_t tv_sec; <-- 8
long int tv_nsec; <-- 4
int: 32; <-- 4
};
struct stat64
{
...
struct timespec st_atim; <-- offset 72
struct timespec st_mtim; <-- offset *88*
struct timespec st_ctim; <-- offset 104
int __glibc_reserved[2];
};
However glibc stat64()wrapper calls
sysdeps/unix/sysv/linux/generic/wordsize-32/xstat64.c
which for ARC is just doing a pass thru syscall because we do have __NR_fstatat64
- hence the issues I see.
It needs itemized copy
__xstat64 (int vers, const char *name, struct stat64 *buf)
{
#ifdef __NR_fstatat64
return INLINE_SYSCALL (fstatat64, 4, AT_FDCWD, name, buf, 0);
#else
....
int rc = INLINE_SYSCALL (statx, 5, AT_FDCWD, name, AT_NO_AUTOMOUNT,
STATX_BASIC_STATS, &tmp);
__cp_stat64_statx (buf, &tmp);
#endif
An the reason this all works on RISCV is that your kernel doesn't define
__ARCH_WANT_STAT64 -> lacks __NR_statat64 and instead uses the statx call which
does itemized copy and would work fine when copying from 32-bits time (in kernel)
to 64-bits container in glibc. Is this is right understanding or am I missing
something here.
How do I build a latest RISCV 32-bit kernel + userland - do you have a buildroot
branch somewhere that I can build / test with qemu ?
Thx,
-Vineet
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-18 23:05 ` switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64) Vineet Gupta
@ 2020-02-18 23:13 ` Joseph Myers
2020-02-19 23:09 ` Lukasz Majewski
2020-02-19 23:11 ` Lukasz Majewski
1 sibling, 1 reply; 138+ messages in thread
From: Joseph Myers @ 2020-02-18 23:13 UTC (permalink / raw)
To: Vineet Gupta
Cc: Alistair Francis, Florian Weimer, GNU C Library, Arnd Bergmann,
Palmer Dabbelt, Zong Li, Alistair Francis, Adhemerval Zanella,
Maciej W. Rozycki, arcml
On Tue, 18 Feb 2020, Vineet Gupta wrote:
> An the reason this all works on RISCV is that your kernel doesn't define
> __ARCH_WANT_STAT64 -> lacks __NR_statat64 and instead uses the statx call which
> does itemized copy and would work fine when copying from 32-bits time (in kernel)
> to 64-bits container in glibc. Is this is right understanding or am I missing
> something here.
That looks right - so you'll need a way (e.g. a new macro in
kernel_stat.h) to tell the stat implementations to use the statx path even
though the older stat64 syscalls exist.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-18 23:13 ` Joseph Myers
@ 2020-02-19 23:09 ` Lukasz Majewski
0 siblings, 0 replies; 138+ messages in thread
From: Lukasz Majewski @ 2020-02-19 23:09 UTC (permalink / raw)
To: Joseph Myers, Vineet Gupta
Cc: Alistair Francis, Florian Weimer, GNU C Library, Arnd Bergmann,
Palmer Dabbelt, Zong Li, Alistair Francis, Adhemerval Zanella,
Maciej W. Rozycki, arcml
[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]
Hi Joseph, Vineet,
> On Tue, 18 Feb 2020, Vineet Gupta wrote:
>
> > An the reason this all works on RISCV is that your kernel doesn't
> > define __ARCH_WANT_STAT64 -> lacks __NR_statat64 and instead uses
> > the statx call which does itemized copy and would work fine when
> > copying from 32-bits time (in kernel) to 64-bits container in
> > glibc. Is this is right understanding or am I missing something
> > here.
>
> That looks right - so you'll need a way (e.g. a new macro in
> kernel_stat.h) to tell the stat implementations to use the statx path
> even though the older stat64 syscalls exist.
>
Similar issue is on ARM32 (armv7). It also uses stat instead of statx
(and also needs some conversion to 64 bit types). Potential conversion
patch could be reused on ARM32 as well.
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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-18 23:05 ` switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64) Vineet Gupta
2020-02-18 23:13 ` Joseph Myers
@ 2020-02-19 23:11 ` Lukasz Majewski
2020-02-20 8:31 ` Arnd Bergmann
1 sibling, 1 reply; 138+ messages in thread
From: Lukasz Majewski @ 2020-02-19 23:11 UTC (permalink / raw)
To: Vineet Gupta
Cc: Alistair Francis, Joseph Myers, Florian Weimer, GNU C Library,
Arnd Bergmann, Palmer Dabbelt, Zong Li, Alistair Francis,
Adhemerval Zanella, Maciej W. Rozycki, arcml
[-- Attachment #1: Type: text/plain, Size: 5379 bytes --]
Hi Vineet,
> Hi Alistair, Arnd
>
> On 2/14/20 2:39 PM, Alistair Francis wrote:
> > On Tue, Feb 11, 2020 at 5:30 PM Joseph Myers
> > <joseph@codesourcery.com> wrote:
> >> On Tue, 11 Feb 2020, Alistair Francis wrote:
> >>
> >>>>> 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..0da3bdeb5d
> >>>>> --- /dev/null
> >>>>> +++ b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
> >>>> I was hoping newer arches could simply use the asm-generic one ?
> >>>>
> >>> We need to specify that RV32 uses a 64-bit time_t. The generic
> >>> ones don't do that for 32-bit arches.
> >> Since it seems we'd like future 32-bit ports of glibc to use
> >> 64-bit time and offsets, we should make that as easy as possible.
> >>
> >> That is, you need an RISC-V-specific bits/timesize.h. But you
> >> shouldn't need an RISC-V-specific bits/typesizes.h - rather, make
> >> the linux/generic one do the right thing for __TIME_T_TYPE based
> >> on bits/timesize.h. And have some other header that 32-bit
> >> linux/generic ports can use to say whether they use the 64-bit
> >> offset/stat/statfs interface, that bits/typesizes.h can use
> >> together with its existing __LP64__ check, and make the
> >> definitions of __OFF_T_TYPE etc. check that as well, and then you
> >> shouldn't need an RISC-V-specific bits/typesizes.h - the
> >> RISC-V-specific headers should be strictly minimal. (No
> >> architecture-specific bits/time64.h headers should be needed in
> >> any case.)
> > Ok, I have updated this. I'll send the patch once my "Always use
> > 32-bit time_t for certain syscalls" series is in (the headers are
> > changed in that series).
>
> I guess you haven't pushed changes yet, which don't make full copy of
> typesizes.h ?
>
> Anyhow I have a version based on your prior next branch where I
> switched ARC to 64-bit time_t - things work fine in general but I see
> some additional failures with the testsuite.
>
> Consider io/test-stat2.c which calls stat() and stat64() and compares
> the results: it now fails for ctime mismatch
>
> | ...
> | st_atime: [72] 644245094405576070 vs [72] 644245094405576070 OK
> | st_mtime: [88] 1975684956160000000 vs [88] 1975684956160000000 OK
> | st_ctime: [104] 0 vs [104] 2306351876938924035 FAIL
>
>
> In kernel asm-generic stat64 has 32-bit ctime (secs)
>
> struct stat64 {
> ...
> int st_atime; <-- offset 72
> unsigned int st_atime_nsec;
> int st_mtime; <-- offset *80*
> unsigned int st_mtime_nsec;
> int st_ctime; <-- offset 92
> unsigned int st_ctime_nsec;
> ...
> };
>
> In glibc, we have 64-bit time_t based timestamps so the structure
> diverges with kernel counterpart from time fields onwards.
>
> __extension__ typedef __int64_t __time_t; <-- ARC switched
> to 64-bit time_t
>
> struct timespec
> {
> __time_t tv_sec; <-- 8
> long int tv_nsec; <-- 4
> int: 32; <-- 4
> };
>
> struct stat64
> {
> ...
> struct timespec st_atim; <-- offset 72
> struct timespec st_mtim; <-- offset *88*
> struct timespec st_ctim; <-- offset 104
> int __glibc_reserved[2];
> };
>
> However glibc stat64()wrapper calls
> sysdeps/unix/sysv/linux/generic/wordsize-32/xstat64.c
>
> which for ARC is just doing a pass thru syscall because we do have
> __NR_fstatat64
> - hence the issues I see.
>
> It needs itemized copy
>
> __xstat64 (int vers, const char *name, struct stat64 *buf)
> {
> #ifdef __NR_fstatat64
> return INLINE_SYSCALL (fstatat64, 4, AT_FDCWD, name, buf,
> 0); #else
> ....
> int rc = INLINE_SYSCALL (statx, 5, AT_FDCWD, name,
> AT_NO_AUTOMOUNT, STATX_BASIC_STATS, &tmp);
> __cp_stat64_statx (buf, &tmp);
> #endif
>
> An the reason this all works on RISCV is that your kernel doesn't
> define __ARCH_WANT_STAT64 -> lacks __NR_statat64 and instead uses the
> statx call which does itemized copy and would work fine when copying
> from 32-bits time (in kernel) to 64-bits container in glibc. Is this
> is right understanding or am I missing something here.
>
> How do I build a latest RISCV 32-bit kernel + userland - do you have
> a buildroot branch somewhere that I can build / test with qemu ?
Maybe a bit off topic - there is such QEMU and Yocto/OE based test
sandbox for ARM32:
https://github.com/lmajewski/meta-y2038
(the README provides steps for setup).
>
> Thx,
> -Vineet
>
>
>
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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-19 23:11 ` Lukasz Majewski
@ 2020-02-20 8:31 ` Arnd Bergmann
2020-02-20 9:37 ` Lukasz Majewski
2020-02-20 16:27 ` Helmut Grohne
0 siblings, 2 replies; 138+ messages in thread
From: Arnd Bergmann @ 2020-02-20 8:31 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Vineet Gupta, Alistair Francis, Joseph Myers, Florian Weimer,
GNU C Library, Palmer Dabbelt, Zong Li, Alistair Francis,
Adhemerval Zanella, Maciej W. Rozycki, arcml, debian-arm,
Helmut Grohne
On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski <lukma@denx.de> wrote:
> > On 2/14/20 2:39 PM, Alistair Francis wrote:
> > > On Tue, Feb 11, 2020 at 5:30 PM Joseph Myers
> > An the reason this all works on RISCV is that your kernel doesn't
> > define __ARCH_WANT_STAT64 -> lacks __NR_statat64 and instead uses the
> > statx call which does itemized copy and would work fine when copying
> > from 32-bits time (in kernel) to 64-bits container in glibc. Is this
> > is right understanding or am I missing something here.
> >
> > How do I build a latest RISCV 32-bit kernel + userland - do you have
> > a buildroot branch somewhere that I can build / test with qemu ?
>
> Maybe a bit off topic - there is such QEMU and Yocto/OE based test
> sandbox for ARM32:
>
> https://github.com/lmajewski/meta-y2038
>
> (the README provides steps for setup).
(continuing off-topic, with debian-arm and Helmut on Cc)
Would it be possible to take a snapshot of your glibc tree and
start testing this out with debian-rebootstrap [1]?
Are there any glibc issues that prevent it from working correctly,
aside from the exact ABI not being final yet?
Arnd
[1] https://wiki.debian.org/HelmutGrohne/rebootstrap
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-20 8:31 ` Arnd Bergmann
@ 2020-02-20 9:37 ` Lukasz Majewski
2020-02-20 12:37 ` Arnd Bergmann
2020-02-22 8:42 ` Arnd Bergmann
2020-02-20 16:27 ` Helmut Grohne
1 sibling, 2 replies; 138+ messages in thread
From: Lukasz Majewski @ 2020-02-20 9:37 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Vineet Gupta, Alistair Francis, Joseph Myers, Florian Weimer,
GNU C Library, Palmer Dabbelt, Zong Li, Alistair Francis,
Adhemerval Zanella, Maciej W. Rozycki, arcml, debian-arm,
Helmut Grohne
[-- Attachment #1: Type: text/plain, Size: 3197 bytes --]
Hi Arnd,
> On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski <lukma@denx.de>
> wrote:
> > > On 2/14/20 2:39 PM, Alistair Francis wrote:
> > > > On Tue, Feb 11, 2020 at 5:30 PM Joseph Myers
> > > An the reason this all works on RISCV is that your kernel doesn't
> > > define __ARCH_WANT_STAT64 -> lacks __NR_statat64 and instead uses
> > > the statx call which does itemized copy and would work fine when
> > > copying from 32-bits time (in kernel) to 64-bits container in
> > > glibc. Is this is right understanding or am I missing something
> > > here.
> > >
> > > How do I build a latest RISCV 32-bit kernel + userland - do you
> > > have a buildroot branch somewhere that I can build / test with
> > > qemu ?
> >
> > Maybe a bit off topic - there is such QEMU and Yocto/OE based test
> > sandbox for ARM32:
> >
> > https://github.com/lmajewski/meta-y2038
> >
> > (the README provides steps for setup).
>
> (continuing off-topic, with debian-arm and Helmut on Cc)
>
> Would it be possible to take a snapshot of your glibc tree
The description of the status of Y2038 supporting glibc on ARM 32 can
be found here [1].
The most recent patches for Y2038 supporting glibc can be always found
in the 'y2038_edge' branch [2].
I also do have a 'warrior' based glibc branch [3], which is a bunch of
hacks to have glibc 2.29 Y2038 supporting. However, my policy now is
"upstream first" - so I would recommend adding any further glibc work
on top of [2].
> and
> start testing this out with debian-rebootstrap [1]?
I've been using OE/Yocto for testing as it allows building glibc
sources for x86_64, x86, x86-x32, arm32 (probably also for ppc32 and
mips - but not tested).
I'm able to use runqemu to test the built glibc with kernel 4.19, 5.1
(for armv7).
This qemu run system can be used to run-test glibc tests on ARM32 with
test-wrapper='/opt/Y2038/glibc/src/scripts/cross-test-ssh.sh
Last but not least - OE/Yocto is used to provide BSP for embedded
systems, so I'm aligned with customers' needs.
However, I did not yet tried debian-rebootstrap. I will look if this
can be reused as well.
>
> Are there any glibc issues that prevent it from working correctly,
I think that the glibc wrappers for most important syscalls are now
converted.
What is missing:
- NTPL (threads)
- stat
- In-glibc test coverage when -D_TIME_BITS=64 is used. I do have
some basic tests [4], but this may be not enough.
> aside from the exact ABI not being final yet?
>
> Arnd
>
> [1] https://wiki.debian.org/HelmutGrohne/rebootstrap
Links:
[1] -
https://github.com/lmajewski/y2038_glibc/commit/4f72f695d1ac428fe945cd7d5e95770180d4a7c1
[2] - https://github.com/lmajewski/y2038_glibc/commits/y2038_edge
[3] -
https://github.com/lmajewski/y2038_glibc/commits/Y2038-2.29-glibc-warrior-01-08-2019
[4] - https://github.com/lmajewski/y2038-tests
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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-20 9:37 ` Lukasz Majewski
@ 2020-02-20 12:37 ` Arnd Bergmann
2020-02-20 13:14 ` Lukasz Majewski
2020-02-21 19:56 ` Alistair Francis
2020-02-22 8:42 ` Arnd Bergmann
1 sibling, 2 replies; 138+ messages in thread
From: Arnd Bergmann @ 2020-02-20 12:37 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Vineet Gupta, Alistair Francis, Joseph Myers, Florian Weimer,
GNU C Library, Palmer Dabbelt, Zong Li, Alistair Francis,
Adhemerval Zanella, Maciej W. Rozycki, arcml, debian-arm,
Helmut Grohne
On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@denx.de> wrote:
> > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski <lukma@denx.de>
> >
> > Would it be possible to take a snapshot of your glibc tree
>
> The description of the status of Y2038 supporting glibc on ARM 32 can
> be found here [1].
>
> The most recent patches for Y2038 supporting glibc can be always found
> in the 'y2038_edge' branch [2].
Ok.
> > and start testing this out with debian-rebootstrap [1]?
>
> I've been using OE/Yocto for testing as it allows building glibc
> sources for x86_64, x86, x86-x32, arm32 (probably also for ppc32 and
> mips - but not tested).
>...
> However, I did not yet tried debian-rebootstrap. I will look if this
> can be reused as well.
The reason I'm asking about debian-rebootstrap is less about testing
glibc itself than about testing the rest of user space to figure out better
what needs to be done when rebuilding with _TIME_BITS=64, and to
start fixing more upstream packages, with the hope of having enough
of it done in time for the Debian 11 release.
> > Are there any glibc issues that prevent it from working correctly,
>
> I think that the glibc wrappers for most important syscalls are now
> converted.
>
> What is missing:
>
> - NTPL (threads)
> - stat
Do you mean that code using these will fail to work correctly with
-D_TIME_BITS=64 at the moment, or that the interfaces are there
but they are not y2038 safe? Without pthreads or stat, we probably
wouldn't get too far in rebootstrap, but if the interfaces are there
and mostly work, then we don't need to rely on them being
y2038-safe just yet. An obvious next step would be to run the
resulting code with the RTC set 20 years ahead, and that requires
it all to work.
> - In-glibc test coverage when -D_TIME_BITS=64 is used. I do have
> some basic tests [4], but this may be not enough.
This is probably something where debian-rebootstrap could help,
as building and testing more user space packages will excercise
additional code paths in glibc as well. There is also some work
in Linaro to ensure that LTP tests the low-level syscall interfaces
in both the time32 and time64 variants.
Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-20 12:37 ` Arnd Bergmann
@ 2020-02-20 13:14 ` Lukasz Majewski
2020-02-20 14:44 ` Arnd Bergmann
2020-02-21 19:56 ` Alistair Francis
1 sibling, 1 reply; 138+ messages in thread
From: Lukasz Majewski @ 2020-02-20 13:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Vineet Gupta, Alistair Francis, Joseph Myers, Florian Weimer,
GNU C Library, Palmer Dabbelt, Zong Li, Alistair Francis,
Adhemerval Zanella, Maciej W. Rozycki, arcml, debian-arm,
Helmut Grohne
[-- Attachment #1: Type: text/plain, Size: 4466 bytes --]
Hi Arnd,
> On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@denx.de>
> wrote:
> > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski <lukma@denx.de>
> > >
> > > Would it be possible to take a snapshot of your glibc tree
> >
> > The description of the status of Y2038 supporting glibc on ARM 32
> > can be found here [1].
> >
> > The most recent patches for Y2038 supporting glibc can be always
> > found in the 'y2038_edge' branch [2].
>
> Ok.
>
> > > and start testing this out with debian-rebootstrap [1]?
> >
> > I've been using OE/Yocto for testing as it allows building glibc
> > sources for x86_64, x86, x86-x32, arm32 (probably also for ppc32 and
> > mips - but not tested).
> >...
> > However, I did not yet tried debian-rebootstrap. I will look if this
> > can be reused as well.
>
> The reason I'm asking about debian-rebootstrap is less about testing
> glibc itself than about testing the rest of user space to figure out
> better what needs to be done when rebuilding with _TIME_BITS=64, and
> to start fixing more upstream packages, with the hope of having enough
> of it done in time for the Debian 11 release.
Ok. I see. Thanks for the information.
Validating the packages was one of the reasons to move from some custom
made test images/setup to Yocto/OE (as it is very close to customers
needs).
>
> > > Are there any glibc issues that prevent it from working
> > > correctly,
> >
> > I think that the glibc wrappers for most important syscalls are now
> > converted.
> >
> > What is missing:
> >
> > - NTPL (threads)
> > - stat
>
> Do you mean that code using these will fail to work correctly with
> -D_TIME_BITS=64 at the moment, or that the interfaces are there
> but they are not y2038 safe?
For ARM32 (branch [2]):
- Without -D_TIME_BITS=64 defined during compilation (as we do have
now) the glibc is fully functional, but when you set date after
03:14:08 UTC on 19.01.2038 you will see the date reset (to 1901) in
the user space programs (after calling e.g. 'date').
- With -D_TIME_BITS=64 set during compilation - and using branch [2] -
syscalls listed in [1] will provide correct date after Y2038 32 bit
overflow. Other (i.e. not converted ones) will use overflow date (1901
year). The glibc will also be fully functional up till Y2038 overflow.
> Without pthreads or stat, we probably
> wouldn't get too far in rebootstrap, but if the interfaces are there
> and mostly work, then we don't need to rely on them being
> y2038-safe just yet.
According to my above statement the second assumption is correct.
> An obvious next step would be to run the
> resulting code with the RTC set 20 years ahead, and that requires
> it all to work.
Yes. This is what I do for the test setup [3]. I do use
clock_settime syscall (now it is working correctly) or just 'date'
from user space.
>
> > - In-glibc test coverage when -D_TIME_BITS=64 is used. I do have
> > some basic tests [4], but this may be not enough.
>
> This is probably something where debian-rebootstrap could help,
> as building and testing more user space packages will excercise
> additional code paths in glibc as well.
Yes this _could_ help. Do you have any tutorial/howto similar to one
from [4]?
I also think that some tests from debian-rebootstrap could be moved to
glibc test framework (test suite). For example tests for
clock_settime/gettime/nanosleep/ etc. In that way the
glibc-many-build.py would run those tests for all supported ports.
Then the debian-rebootstrap could test for more sophisticated bugs
(like dependencies between syscalls, etc).
> There is also some work
> in Linaro to ensure that LTP tests the low-level syscall interfaces
> in both the time32 and time64 variants.
Interesting. Is this work now publicly available?
>
> Arnd
Links:
[1] -
https://github.com/lmajewski/y2038_glibc/commit/4f72f695d1ac428fe945cd7d5e95770180d4a7c1
[2] - https://github.com/lmajewski/y2038_glibc/commits/y2038_edge
[3] - https://github.com/lmajewski/y2038-tests
[4] - https://github.com/lmajewski/meta-y2038/blob/master/README
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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-20 13:14 ` Lukasz Majewski
@ 2020-02-20 14:44 ` Arnd Bergmann
2020-02-20 15:42 ` Lukasz Majewski
2020-02-24 2:48 ` Viresh Kumar
0 siblings, 2 replies; 138+ messages in thread
From: Arnd Bergmann @ 2020-02-20 14:44 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Vineet Gupta, Alistair Francis, Joseph Myers, Florian Weimer,
GNU C Library, Palmer Dabbelt, Zong Li, Alistair Francis,
Adhemerval Zanella, Maciej W. Rozycki, arcml, debian-arm,
Helmut Grohne, Viresh Kumar
On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski <lukma@denx.de> wrote:
> > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@denx.de>
> > wrote:
> > > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski <lukma@denx.de>
> > > > Are there any glibc issues that prevent it from working
> > > > correctly,
> > >
> > > I think that the glibc wrappers for most important syscalls are now
> > > converted.
> > >
> > > What is missing:
> > >
> > > - NTPL (threads)
> > > - stat
> >
> > Do you mean that code using these will fail to work correctly with
> > -D_TIME_BITS=64 at the moment, or that the interfaces are there
> > but they are not y2038 safe?
>
> For ARM32 (branch [2]):
>
> - Without -D_TIME_BITS=64 defined during compilation (as we do have
> now) the glibc is fully functional, but when you set date after
> 03:14:08 UTC on 19.01.2038 you will see the date reset (to 1901) in
> the user space programs (after calling e.g. 'date').
I'd actually consider intentionally breaking this for a Debian bootstrap,
at least initially, so that any application that accidentally gets built without
-D_TIME_BITS=64 runs into a build or link failure.
> - With -D_TIME_BITS=64 set during compilation - and using branch [2] -
> syscalls listed in [1] will provide correct date after Y2038 32 bit
> overflow. Other (i.e. not converted ones) will use overflow date (1901
> year). The glibc will also be fully functional up till Y2038 overflow.
Ok.
> > > - In-glibc test coverage when -D_TIME_BITS=64 is used. I do have
> > > some basic tests [4], but this may be not enough.
> >
> > This is probably something where debian-rebootstrap could help,
> > as building and testing more user space packages will excercise
> > additional code paths in glibc as well.
>
> Yes this _could_ help. Do you have any tutorial/howto similar to one
> from [4]?
Not sure, maybe Helmut has some references.
> > There is also some work
> > in Linaro to ensure that LTP tests the low-level syscall interfaces
> > in both the time32 and time64 variants.
>
> Interesting. Is this work now publicly available?
I think this is currently in the planning stage, but once patches
are available, they would be posted to the ltp mailing list. Viresh
should have more details on this.
Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-20 14:44 ` Arnd Bergmann
@ 2020-02-20 15:42 ` Lukasz Majewski
2020-02-20 16:08 ` Arnd Bergmann
2020-02-24 2:48 ` Viresh Kumar
1 sibling, 1 reply; 138+ messages in thread
From: Lukasz Majewski @ 2020-02-20 15:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Vineet Gupta, Alistair Francis, Joseph Myers, Florian Weimer,
GNU C Library, Palmer Dabbelt, Zong Li, Alistair Francis,
Adhemerval Zanella, Maciej W. Rozycki, arcml, debian-arm,
Helmut Grohne, Viresh Kumar
[-- Attachment #1: Type: text/plain, Size: 3254 bytes --]
Hi Arnd,
> On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski <lukma@denx.de> wrote:
> > > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@denx.de>
> > > wrote:
> > > > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski
> > > > > <lukma@denx.de> Are there any glibc issues that prevent it
> > > > > from working correctly,
> > > >
> > > > I think that the glibc wrappers for most important syscalls are
> > > > now converted.
> > > >
> > > > What is missing:
> > > >
> > > > - NTPL (threads)
> > > > - stat
> > >
> > > Do you mean that code using these will fail to work correctly with
> > > -D_TIME_BITS=64 at the moment, or that the interfaces are there
> > > but they are not y2038 safe?
> >
> > For ARM32 (branch [2]):
> >
> > - Without -D_TIME_BITS=64 defined during compilation (as we do have
> > now) the glibc is fully functional, but when you set date after
> > 03:14:08 UTC on 19.01.2038 you will see the date reset (to 1901)
> > in the user space programs (after calling e.g. 'date').
>
> I'd actually consider intentionally breaking this for a Debian
> bootstrap, at least initially, so that any application that
> accidentally gets built without -D_TIME_BITS=64 runs into a build or
> link failure.
I do see two approaches here:
1. In glibc:
When -D_TIME_BITS=64 is set - redirections are enabled for syscall
wrappers; for example __clock_settime64 is used instead of
__clock_settime (e.g. sysdeps/unix/sysv/linux/clock_settime).
The latter is guarded by #ifdef __TIMESIZE != 64 so we could change
mechanically that __clock_settime returns -1 and sets errno to -ENOTSUPP
2. In kernel - return -ENOTSUPP when clock_settime syscall instead of
clock_settime64 is invoked.
>
> > - With -D_TIME_BITS=64 set during compilation - and using branch
> > [2] - syscalls listed in [1] will provide correct date after Y2038
> > 32 bit overflow. Other (i.e. not converted ones) will use overflow
> > date (1901 year). The glibc will also be fully functional up till
> > Y2038 overflow.
>
> Ok.
>
> > > > - In-glibc test coverage when -D_TIME_BITS=64 is used. I do have
> > > > some basic tests [4], but this may be not enough.
> > >
> > > This is probably something where debian-rebootstrap could help,
> > > as building and testing more user space packages will excercise
> > > additional code paths in glibc as well.
> >
> > Yes this _could_ help. Do you have any tutorial/howto similar to one
> > from [4]?
>
> Not sure, maybe Helmut has some references.
>
> > > There is also some work
> > > in Linaro to ensure that LTP tests the low-level syscall
> > > interfaces in both the time32 and time64 variants.
> >
> > Interesting. Is this work now publicly available?
>
> I think this is currently in the planning stage, but once patches
> are available, they would be posted to the ltp mailing list. Viresh
> should have more details on this.
>
> 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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-20 15:42 ` Lukasz Majewski
@ 2020-02-20 16:08 ` Arnd Bergmann
2020-02-20 16:31 ` Lukasz Majewski
0 siblings, 1 reply; 138+ messages in thread
From: Arnd Bergmann @ 2020-02-20 16:08 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Vineet Gupta, Alistair Francis, Joseph Myers, Florian Weimer,
GNU C Library, Palmer Dabbelt, Zong Li, Alistair Francis,
Adhemerval Zanella, Maciej W. Rozycki, arcml, debian-arm,
Helmut Grohne, Viresh Kumar
On Thu, Feb 20, 2020 at 4:42 PM Lukasz Majewski <lukma@denx.de> wrote:
> > On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski <lukma@denx.de> wrote:
>
> I do see two approaches here:
>
> 1. In glibc:
>
> When -D_TIME_BITS=64 is set - redirections are enabled for syscall
> wrappers; for example __clock_settime64 is used instead of
> __clock_settime (e.g. sysdeps/unix/sysv/linux/clock_settime).
>
> The latter is guarded by #ifdef __TIMESIZE != 64 so we could change
> mechanically that __clock_settime returns -1 and sets errno to -ENOTSUPP
What I meant is to remove the __clock_settime function from the
library entirely to cause a link failure. I suppose replacing most
"__TIMESIZE != 64" with '0' would do that. Ideally I'd just set
__TIMESIZE to 64, but doing that would make the ABI incompatible
with mainline glibc.
> 2. In kernel - return -ENOTSUPP when clock_settime syscall instead of
> clock_settime64 is invoked.
We already have that with CONFIG_COMPAT_32BIT_TIME, but
at the moment I think that still breaks glibc's usage of __NR_futex,
and a compile-time error is always better than a runtime error,
as it's easier to catch them reliably
Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-20 16:08 ` Arnd Bergmann
@ 2020-02-20 16:31 ` Lukasz Majewski
0 siblings, 0 replies; 138+ messages in thread
From: Lukasz Majewski @ 2020-02-20 16:31 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Vineet Gupta, Alistair Francis, Joseph Myers, Florian Weimer,
GNU C Library, Palmer Dabbelt, Zong Li, Alistair Francis,
Adhemerval Zanella, Maciej W. Rozycki, arcml, debian-arm,
Helmut Grohne, Viresh Kumar
[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]
Hi Arnd,
> On Thu, Feb 20, 2020 at 4:42 PM Lukasz Majewski <lukma@denx.de> wrote:
> > > On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski <lukma@denx.de>
> > > wrote:
>
> >
> > I do see two approaches here:
> >
> > 1. In glibc:
> >
> > When -D_TIME_BITS=64 is set - redirections are enabled for syscall
> > wrappers; for example __clock_settime64 is used instead of
> > __clock_settime (e.g. sysdeps/unix/sysv/linux/clock_settime).
> >
> > The latter is guarded by #ifdef __TIMESIZE != 64 so we could change
> > mechanically that __clock_settime returns -1 and sets errno to
> > -ENOTSUPP
>
> What I meant is to remove the __clock_settime function from the
> library entirely to cause a link failure. I suppose replacing most
> "__TIMESIZE != 64" with '0' would do that. Ideally I'd just set
I think that replacing "__TIMESIZE != 64" with '0' would be the
simplest option.
> __TIMESIZE to 64, but doing that would make the ABI incompatible
> with mainline glibc.
>
> > 2. In kernel - return -ENOTSUPP when clock_settime syscall instead
> > of clock_settime64 is invoked.
>
> We already have that with CONFIG_COMPAT_32BIT_TIME, but
> at the moment I think that still breaks glibc's usage of __NR_futex,
> and a compile-time error is always better than a runtime error,
> as it's easier to catch them reliably
Ok.
>
> 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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-20 14:44 ` Arnd Bergmann
2020-02-20 15:42 ` Lukasz Majewski
@ 2020-02-24 2:48 ` Viresh Kumar
1 sibling, 0 replies; 138+ messages in thread
From: Viresh Kumar @ 2020-02-24 2:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Lukasz Majewski, Vineet Gupta, Alistair Francis, Joseph Myers,
Florian Weimer, GNU C Library, Palmer Dabbelt, Zong Li,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki, arcml,
debian-arm, Helmut Grohne, Viresh Kumar
On 20-02-20, 15:44, Arnd Bergmann wrote:
> On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski <lukma@denx.de> wrote:
> > > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@denx.de>
> > > > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski <lukma@denx.de>
> > > There is also some work
> > > in Linaro to ensure that LTP tests the low-level syscall interfaces
> > > in both the time32 and time64 variants.
> >
> > Interesting. Is this work now publicly available?
>
> I think this is currently in the planning stage, but once patches
> are available, they would be posted to the ltp mailing list. Viresh
> should have more details on this.
What you said is correct Arnd. It is in very early stage of planning
right now, no guarantees on when will we start working on it as of
now.
--
viresh
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-20 12:37 ` Arnd Bergmann
2020-02-20 13:14 ` Lukasz Majewski
@ 2020-02-21 19:56 ` Alistair Francis
1 sibling, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-02-21 19:56 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Lukasz Majewski, Vineet Gupta, Joseph Myers, Florian Weimer,
GNU C Library, Palmer Dabbelt, Zong Li, Alistair Francis,
Adhemerval Zanella, Maciej W. Rozycki, arcml, debian-arm,
Helmut Grohne
On Thu, Feb 20, 2020 at 4:37 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@denx.de> wrote:
> > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski <lukma@denx.de>
> > >
> > > Would it be possible to take a snapshot of your glibc tree
> >
> > The description of the status of Y2038 supporting glibc on ARM 32 can
> > be found here [1].
> >
> > The most recent patches for Y2038 supporting glibc can be always found
> > in the 'y2038_edge' branch [2].
>
> Ok.
>
> > > and start testing this out with debian-rebootstrap [1]?
> >
> > I've been using OE/Yocto for testing as it allows building glibc
> > sources for x86_64, x86, x86-x32, arm32 (probably also for ppc32 and
> > mips - but not tested).
> >...
> > However, I did not yet tried debian-rebootstrap. I will look if this
> > can be reused as well.
>
> The reason I'm asking about debian-rebootstrap is less about testing
> glibc itself than about testing the rest of user space to figure out better
> what needs to be done when rebuilding with _TIME_BITS=64, and to
> start fixing more upstream packages, with the hope of having enough
> of it done in time for the Debian 11 release.
We have started to do that for RISC-V 32-bit. I have fixed up some
things in Busybox and OpenSSL to improve 64-bit time_t support on
32-bit archs. In meta-riscv (and OpenEmbedded layer) we are tracking
issues: https://github.com/riscv/meta-riscv/issues/202
Right now it's all compile focused though, not so much run time testing.
Alistair
>
> > > Are there any glibc issues that prevent it from working correctly,
> >
> > I think that the glibc wrappers for most important syscalls are now
> > converted.
> >
> > What is missing:
> >
> > - NTPL (threads)
> > - stat
>
> Do you mean that code using these will fail to work correctly with
> -D_TIME_BITS=64 at the moment, or that the interfaces are there
> but they are not y2038 safe? Without pthreads or stat, we probably
> wouldn't get too far in rebootstrap, but if the interfaces are there
> and mostly work, then we don't need to rely on them being
> y2038-safe just yet. An obvious next step would be to run the
> resulting code with the RTC set 20 years ahead, and that requires
> it all to work.
>
> > - In-glibc test coverage when -D_TIME_BITS=64 is used. I do have
> > some basic tests [4], but this may be not enough.
>
> This is probably something where debian-rebootstrap could help,
> as building and testing more user space packages will excercise
> additional code paths in glibc as well. There is also some work
> in Linaro to ensure that LTP tests the low-level syscall interfaces
> in both the time32 and time64 variants.
>
> Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-20 9:37 ` Lukasz Majewski
2020-02-20 12:37 ` Arnd Bergmann
@ 2020-02-22 8:42 ` Arnd Bergmann
2020-02-24 9:00 ` Lukasz Majewski
1 sibling, 1 reply; 138+ messages in thread
From: Arnd Bergmann @ 2020-02-22 8:42 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Vineet Gupta, Alistair Francis, Joseph Myers, Florian Weimer,
GNU C Library, Palmer Dabbelt, Zong Li, Alistair Francis,
Adhemerval Zanella, Maciej W. Rozycki, arcml, debian-arm,
Helmut Grohne
On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@denx.de> wrote:
> [2] - https://github.com/lmajewski/y2038_glibc/commits/y2038_edge
I tried packaging this into a .deb package for use with rebootstrap, but
ran into a couple of test failures from glibc itself, when testing the i386
version while running on an older x86_64 kernel (4.15):
+---------------------------------------------------------------------+
| Encountered regressions that don't match expected failures. |
+---------------------------------------------------------------------+
FAIL: elf/check-localplt
FAIL: nptl/tst-cancel19
FAIL: rt/tst-mqueue2
make: *** [debian/rules.d/build.mk:116:
/home/arnd/glibc-2.31/stamp-dir/check_i386] Error 1
elf/check-localplt complains about the newly added symbols
Extra PLT reference: libc.so: __lutimes64
Extra PLT reference: libc.so: __wait4_time64
Extra PLT reference: libc.so: __setitimer64
Extra PLT reference: libc.so: __utime64
Extra PLT reference: libc.so: __timerfd_gettime64
Extra PLT reference: libc.so: __clock_settime64
Extra PLT reference: libc.so: __utimes64
Extra PLT reference: libc.so: __gettimeofday64
Extra PLT reference: libc.so: __clock_gettime64
Extra PLT reference: libc.so: __futimesat64
Extra PLT reference: libc.so: __clock_getres64
Extra PLT reference: libc.so: __futimes64
Extra PLT reference: libc.so: __futimens64
Extra PLT reference: libc.so: __utimensat64
Extra PLT reference: libc.so: __getrusage64
Extra PLT reference: libc.so: __timespec_get64
Extra PLT reference: libc.so: __getitimer64
Extra PLT reference: libc.so: __ppoll64
Extra PLT reference: libc.so: __timerfd_settime64
Extra PLT reference: libc.so: __clock_nanosleep_time64
Extra PLT reference: libc.so: __sched_rr_get_interval64
Extra PLT reference: libc.so: __settimeofday64
Extra PLT reference: librt.so: __timer_gettime64
Extra PLT reference: librt.so: __mq_timedreceive_time64
Extra PLT reference: librt.so: __mq_timedsend_time64
Extra PLT reference: librt.so: __timer_settime64
which seems a bug in the test suite. The other two get a segfault
that I have not debugged, but I guess this is likely a problem in your
patches. Have you seen the same thing?
Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-22 8:42 ` Arnd Bergmann
@ 2020-02-24 9:00 ` Lukasz Majewski
2020-02-24 9:46 ` Andreas Schwab
2020-02-25 9:03 ` Arnd Bergmann
0 siblings, 2 replies; 138+ messages in thread
From: Lukasz Majewski @ 2020-02-24 9:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Vineet Gupta, Alistair Francis, Joseph Myers, Florian Weimer,
GNU C Library, Palmer Dabbelt, Zong Li, Alistair Francis,
Adhemerval Zanella, Maciej W. Rozycki, arcml, debian-arm,
Helmut Grohne
[-- Attachment #1: Type: text/plain, Size: 3367 bytes --]
Hi Arnd,
> On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@denx.de>
> wrote:
>
> > [2] - https://github.com/lmajewski/y2038_glibc/commits/y2038_edge
>
> I tried packaging this into a .deb package for use with rebootstrap,
> but ran into a couple of test failures from glibc itself, when
> testing the i386 version while running on an older x86_64 kernel
> (4.15):
Thanks for testing. I do use 4.19 as the oldest kernel.
>
> +---------------------------------------------------------------------+
> | Encountered regressions that don't match expected failures.
> |
> +---------------------------------------------------------------------+
> FAIL: elf/check-localplt FAIL: nptl/tst-cancel19
> FAIL: rt/tst-mqueue2
> make: *** [debian/rules.d/build.mk:116:
> /home/arnd/glibc-2.31/stamp-dir/check_i386] Error 1
>
> elf/check-localplt complains about the newly added symbols
>
> Extra PLT reference: libc.so: __lutimes64
> Extra PLT reference: libc.so: __wait4_time64
> Extra PLT reference: libc.so: __setitimer64
> Extra PLT reference: libc.so: __utime64
> Extra PLT reference: libc.so: __timerfd_gettime64
> Extra PLT reference: libc.so: __clock_settime64
> Extra PLT reference: libc.so: __utimes64
> Extra PLT reference: libc.so: __gettimeofday64
> Extra PLT reference: libc.so: __clock_gettime64
> Extra PLT reference: libc.so: __futimesat64
> Extra PLT reference: libc.so: __clock_getres64
> Extra PLT reference: libc.so: __futimes64
> Extra PLT reference: libc.so: __futimens64
> Extra PLT reference: libc.so: __utimensat64
> Extra PLT reference: libc.so: __getrusage64
> Extra PLT reference: libc.so: __timespec_get64
> Extra PLT reference: libc.so: __getitimer64
> Extra PLT reference: libc.so: __ppoll64
> Extra PLT reference: libc.so: __timerfd_settime64
> Extra PLT reference: libc.so: __clock_nanosleep_time64
> Extra PLT reference: libc.so: __sched_rr_get_interval64
> Extra PLT reference: libc.so: __settimeofday64
> Extra PLT reference: librt.so: __timer_gettime64
> Extra PLT reference: librt.so: __mq_timedreceive_time64
> Extra PLT reference: librt.so: __mq_timedsend_time64
> Extra PLT reference: librt.so: __timer_settime64
>
The above problems are somewhat expected. Those are redirected symbols,
which are exported as GLIBC_PRIVATE in several Versions files.
I do guess that we will have a consensus if we add those as a "normal"
exported symbols or keep them "private".
> which seems a bug in the test suite. The other two get a segfault
> that I have not debugged, but I guess this is likely a problem in your
> patches. Have you seen the same thing?
I only do run the full (including full test suite) glibc-many-build
(and my Y2038 tests) on the patches which I post to glibc-alpha.
The Y2038 changes I do test manually if they work as expected - but I
do not run yet the (full) test suites on it, as first _all_ glibc
functions needs to be converted before _TIME_BITS=64 is added.
The issue is probably with the redirection code. I will look on them
soon.
>
> 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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-24 9:00 ` Lukasz Majewski
@ 2020-02-24 9:46 ` Andreas Schwab
2020-02-24 10:14 ` Lukasz Majewski
2020-02-25 9:03 ` Arnd Bergmann
1 sibling, 1 reply; 138+ messages in thread
From: Andreas Schwab @ 2020-02-24 9:46 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Arnd Bergmann, Florian Weimer, Helmut Grohne, GNU C Library,
Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
Alistair Francis, arcml, Joseph Myers
On Feb 24 2020, Lukasz Majewski wrote:
>> elf/check-localplt complains about the newly added symbols
>>
>> Extra PLT reference: libc.so: __lutimes64
>> Extra PLT reference: libc.so: __wait4_time64
>> Extra PLT reference: libc.so: __setitimer64
>> Extra PLT reference: libc.so: __utime64
>> Extra PLT reference: libc.so: __timerfd_gettime64
>> Extra PLT reference: libc.so: __clock_settime64
>> Extra PLT reference: libc.so: __utimes64
>> Extra PLT reference: libc.so: __gettimeofday64
>> Extra PLT reference: libc.so: __clock_gettime64
>> Extra PLT reference: libc.so: __futimesat64
>> Extra PLT reference: libc.so: __clock_getres64
>> Extra PLT reference: libc.so: __futimes64
>> Extra PLT reference: libc.so: __futimens64
>> Extra PLT reference: libc.so: __utimensat64
>> Extra PLT reference: libc.so: __getrusage64
>> Extra PLT reference: libc.so: __timespec_get64
>> Extra PLT reference: libc.so: __getitimer64
>> Extra PLT reference: libc.so: __ppoll64
>> Extra PLT reference: libc.so: __timerfd_settime64
>> Extra PLT reference: libc.so: __clock_nanosleep_time64
>> Extra PLT reference: libc.so: __sched_rr_get_interval64
>> Extra PLT reference: libc.so: __settimeofday64
>> Extra PLT reference: librt.so: __timer_gettime64
>> Extra PLT reference: librt.so: __mq_timedreceive_time64
>> Extra PLT reference: librt.so: __mq_timedsend_time64
>> Extra PLT reference: librt.so: __timer_settime64
>>
>
> The above problems are somewhat expected. Those are redirected symbols,
> which are exported as GLIBC_PRIVATE in several Versions files.
>
> I do guess that we will have a consensus if we add those as a "normal"
> exported symbols or keep them "private".
They need to grow hidden aliases.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-24 9:46 ` Andreas Schwab
@ 2020-02-24 10:14 ` Lukasz Majewski
2020-02-24 10:23 ` Andreas Schwab
0 siblings, 1 reply; 138+ messages in thread
From: Lukasz Majewski @ 2020-02-24 10:14 UTC (permalink / raw)
To: Andreas Schwab
Cc: Arnd Bergmann, Florian Weimer, Helmut Grohne, GNU C Library,
Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
Alistair Francis, arcml, Joseph Myers
[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]
Hi Andreas,
> On Feb 24 2020, Lukasz Majewski wrote:
>
> >> elf/check-localplt complains about the newly added symbols
> >>
> >> Extra PLT reference: libc.so: __lutimes64
> >> Extra PLT reference: libc.so: __wait4_time64
> >> Extra PLT reference: libc.so: __setitimer64
> >> Extra PLT reference: libc.so: __utime64
> >> Extra PLT reference: libc.so: __timerfd_gettime64
> >> Extra PLT reference: libc.so: __clock_settime64
> >> Extra PLT reference: libc.so: __utimes64
> >> Extra PLT reference: libc.so: __gettimeofday64
> >> Extra PLT reference: libc.so: __clock_gettime64
> >> Extra PLT reference: libc.so: __futimesat64
> >> Extra PLT reference: libc.so: __clock_getres64
> >> Extra PLT reference: libc.so: __futimes64
> >> Extra PLT reference: libc.so: __futimens64
> >> Extra PLT reference: libc.so: __utimensat64
> >> Extra PLT reference: libc.so: __getrusage64
> >> Extra PLT reference: libc.so: __timespec_get64
> >> Extra PLT reference: libc.so: __getitimer64
> >> Extra PLT reference: libc.so: __ppoll64
> >> Extra PLT reference: libc.so: __timerfd_settime64
> >> Extra PLT reference: libc.so: __clock_nanosleep_time64
> >> Extra PLT reference: libc.so: __sched_rr_get_interval64
> >> Extra PLT reference: libc.so: __settimeofday64
> >> Extra PLT reference: librt.so: __timer_gettime64
> >> Extra PLT reference: librt.so: __mq_timedreceive_time64
> >> Extra PLT reference: librt.so: __mq_timedsend_time64
> >> Extra PLT reference: librt.so: __timer_settime64
> >>
> >
> > The above problems are somewhat expected. Those are redirected
> > symbols, which are exported as GLIBC_PRIVATE in several Versions
> > files.
> >
> > I do guess that we will have a consensus if we add those as a
> > "normal" exported symbols or keep them "private".
>
> They need to grow hidden aliases.
Could you explain it a bit more?
If I add those functions as hidden_alias then those would be accessible
inside glibc without PLT, but will not be exported (and redirection for
Y2038 will not work).
>
> Andreas.
>
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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-24 10:14 ` Lukasz Majewski
@ 2020-02-24 10:23 ` Andreas Schwab
2020-02-24 10:36 ` Lukasz Majewski
0 siblings, 1 reply; 138+ messages in thread
From: Andreas Schwab @ 2020-02-24 10:23 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Arnd Bergmann, Florian Weimer, Helmut Grohne, GNU C Library,
Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
Alistair Francis, arcml, Joseph Myers
On Feb 24 2020, Lukasz Majewski wrote:
> If I add those functions as hidden_alias then those would be accessible
> inside glibc without PLT, but will not be exported (and redirection for
> Y2038 will not work).
They aren't? PLT avoidance is about internal references, and uses a
different name then the exported sybmol.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-24 10:23 ` Andreas Schwab
@ 2020-02-24 10:36 ` Lukasz Majewski
2020-02-24 10:42 ` Andreas Schwab
2020-02-25 0:03 ` Joseph Myers
0 siblings, 2 replies; 138+ messages in thread
From: Lukasz Majewski @ 2020-02-24 10:36 UTC (permalink / raw)
To: Andreas Schwab
Cc: Arnd Bergmann, Florian Weimer, Helmut Grohne, GNU C Library,
Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
Alistair Francis, arcml, Joseph Myers
[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]
On Mon, 24 Feb 2020 11:23:51 +0100
Andreas Schwab <schwab@suse.de> wrote:
> On Feb 24 2020, Lukasz Majewski wrote:
>
> > If I add those functions as hidden_alias then those would be
> > accessible inside glibc without PLT, but will not be exported (and
> > redirection for Y2038 will not work).
>
> They aren't? PLT avoidance is about internal references, and uses a
> different name then the exported sybmol.
>
I'm probably not aware of something - but as done in the following
patch:
https://github.com/lmajewski/y2038_glibc/commit/c96eeb73175961c4ac80fdd3b6adc132805387c9
I do need to remove librt_hidden_proto / librt_hidden_def to have
proper symbols visible when I do want to use redirections.
(the same issue is with libc_hidden_proto / libc_hidden_def):
https://github.com/lmajewski/y2038_glibc/commit/361f05e38c0d5c6673914af330e766c2ed4f9a8a
> Andreas.
>
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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-24 10:36 ` Lukasz Majewski
@ 2020-02-24 10:42 ` Andreas Schwab
2020-02-24 11:13 ` Lukasz Majewski
2020-02-25 0:03 ` Joseph Myers
1 sibling, 1 reply; 138+ messages in thread
From: Andreas Schwab @ 2020-02-24 10:42 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Arnd Bergmann, Florian Weimer, Helmut Grohne, GNU C Library,
Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
Alistair Francis, arcml, Joseph Myers
On Feb 24 2020, Lukasz Majewski wrote:
> On Mon, 24 Feb 2020 11:23:51 +0100
> Andreas Schwab <schwab@suse.de> wrote:
>
>> On Feb 24 2020, Lukasz Majewski wrote:
>>
>> > If I add those functions as hidden_alias then those would be
>> > accessible inside glibc without PLT, but will not be exported (and
>> > redirection for Y2038 will not work).
>>
>> They aren't? PLT avoidance is about internal references, and uses a
>> different name then the exported sybmol.
>>
>
> I'm probably not aware of something - but as done in the following
> patch:
>
> https://github.com/lmajewski/y2038_glibc/commit/c96eeb73175961c4ac80fdd3b6adc132805387c9
>
> I do need to remove librt_hidden_proto / librt_hidden_def to have
> proper symbols visible when I do want to use redirections.
You cannot redirect to GLIBC_PRIVATE symbols, they are not suposed to be
used by public interfaces. All public interfaces need to use official
versioned symbols.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-24 10:42 ` Andreas Schwab
@ 2020-02-24 11:13 ` Lukasz Majewski
2020-02-24 12:41 ` Lukasz Majewski
0 siblings, 1 reply; 138+ messages in thread
From: Lukasz Majewski @ 2020-02-24 11:13 UTC (permalink / raw)
To: Andreas Schwab
Cc: Arnd Bergmann, Florian Weimer, Helmut Grohne, GNU C Library,
Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
Alistair Francis, arcml, Joseph Myers
[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]
On Mon, 24 Feb 2020 11:42:23 +0100
Andreas Schwab <schwab@suse.de> wrote:
> On Feb 24 2020, Lukasz Majewski wrote:
>
> > On Mon, 24 Feb 2020 11:23:51 +0100
> > Andreas Schwab <schwab@suse.de> wrote:
> >
> >> On Feb 24 2020, Lukasz Majewski wrote:
> >>
> >> > If I add those functions as hidden_alias then those would be
> >> > accessible inside glibc without PLT, but will not be exported
> >> > (and redirection for Y2038 will not work).
> >>
> >> They aren't? PLT avoidance is about internal references, and uses
> >> a different name then the exported sybmol.
> >>
> >
> > I'm probably not aware of something - but as done in the following
> > patch:
> >
> > https://github.com/lmajewski/y2038_glibc/commit/c96eeb73175961c4ac80fdd3b6adc132805387c9
> >
> > I do need to remove librt_hidden_proto / librt_hidden_def to have
> > proper symbols visible when I do want to use redirections.
>
> You cannot redirect to GLIBC_PRIVATE symbols, they are not suposed to
> be used by public interfaces. All public interfaces need to use
> official versioned symbols.
>
I've put those symbols to GLIBC_PRIVATE as up till now many more
functions in glibc needs conversion to support 64 bit time. I need
exported symbols to test if the redirection (and Y2038 safeness on ARM
in general) works.
I also do guess that when we will be heading to expose _TIME_BITS==64
to outside word I would need to add:
GLIBC_2.3X {
clock_settime64;
}
for clock_settime64
and then:
#ifdef __USE_TIME_BITS64
# if defined(__REDIRECT_NTH)
extern int __REDIRECT_NTH (clock_settime, (clockid_t __clock_id, const
struct timespec *__tp), clock_settime64);
# else
# define clock_settime clock_settime64
# endif
#endif
Am I correct ?
> Andreas.
>
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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-24 11:13 ` Lukasz Majewski
@ 2020-02-24 12:41 ` Lukasz Majewski
0 siblings, 0 replies; 138+ messages in thread
From: Lukasz Majewski @ 2020-02-24 12:41 UTC (permalink / raw)
To: Andreas Schwab
Cc: Arnd Bergmann, Florian Weimer, Helmut Grohne, GNU C Library,
Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
Alistair Francis, arcml, Joseph Myers
[-- Attachment #1: Type: text/plain, Size: 2624 bytes --]
Dear All,
> On Mon, 24 Feb 2020 11:42:23 +0100
> Andreas Schwab <schwab@suse.de> wrote:
>
> > On Feb 24 2020, Lukasz Majewski wrote:
> >
> > > On Mon, 24 Feb 2020 11:23:51 +0100
> > > Andreas Schwab <schwab@suse.de> wrote:
> > >
> > >> On Feb 24 2020, Lukasz Majewski wrote:
> > >>
> > >> > If I add those functions as hidden_alias then those would be
> > >> > accessible inside glibc without PLT, but will not be exported
> > >> > (and redirection for Y2038 will not work).
> > >>
> > >> They aren't? PLT avoidance is about internal references, and
> > >> uses a different name then the exported sybmol.
> > >>
> > >
> > > I'm probably not aware of something - but as done in the following
> > > patch:
> > >
> > > https://github.com/lmajewski/y2038_glibc/commit/c96eeb73175961c4ac80fdd3b6adc132805387c9
> > >
> > > I do need to remove librt_hidden_proto / librt_hidden_def to have
> > > proper symbols visible when I do want to use redirections.
> >
> > You cannot redirect to GLIBC_PRIVATE symbols, they are not suposed
> > to be used by public interfaces. All public interfaces need to use
> > official versioned symbols.
> >
>
> I've put those symbols to GLIBC_PRIVATE as up till now many more
> functions in glibc needs conversion to support 64 bit time. I need
> exported symbols to test if the redirection (and Y2038 safeness on ARM
> in general) works.
>
> I also do guess that when we will be heading to expose _TIME_BITS==64
> to outside word I would need to add:
>
> GLIBC_2.3X {
> clock_settime64;
^^^^^^^ - it should be __clock_settime64
> }
>
> for clock_settime64
>
> and then:
>
> #ifdef __USE_TIME_BITS64
> # if defined(__REDIRECT_NTH)
> extern int __REDIRECT_NTH (clock_settime, (clockid_t __clock_id, const
> struct timespec *__tp), clock_settime64);
^^^^^^ - __clock_settime64
> # else
> # define clock_settime clock_settime64
^^^^^^ - __clock_settime64
> # endif
> #endif
>
>
> Am I correct ?
>
> > Andreas.
> >
>
>
> 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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-24 10:36 ` Lukasz Majewski
2020-02-24 10:42 ` Andreas Schwab
@ 2020-02-25 0:03 ` Joseph Myers
2020-02-25 11:39 ` Lukasz Majewski
1 sibling, 1 reply; 138+ messages in thread
From: Joseph Myers @ 2020-02-25 0:03 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Andreas Schwab, Arnd Bergmann, Florian Weimer, Helmut Grohne,
GNU C Library, Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
Alistair Francis, arcml
On Mon, 24 Feb 2020, Lukasz Majewski wrote:
> I'm probably not aware of something - but as done in the following
> patch:
>
> https://github.com/lmajewski/y2038_glibc/commit/c96eeb73175961c4ac80fdd3b6adc132805387c9
>
> I do need to remove librt_hidden_proto / librt_hidden_def to have
> proper symbols visible when I do want to use redirections.
You'll need to explain the actual problem you see, because
lib<name>_hidden_proto / lib<name>_hidden_def are correct for any symbol
that satisfies both of the following properties: (a) it is exported from
shared lib<name> (whether at a public symbol version or version
GLIBC_PRIVATE) and (b) it is also used within the library that defines it.
They are useless but harmless for other symbols.
lib<name>_hidden_proto / lib<name>_hidden_def always need to be used
together, and always need to have <name> matching the name of the shared
library with the symbol. In C code, lib<name>_hidden_proto causes the
function, for both definition and calls, to be redirected to an internal,
hidden-visibility alias, while lib<name>_hidden_def then adds back the
exported name as a non-hidden alias to cause it to be exported from the
shared library in question.
It's true that the redirection from lib<name>_hidden_proto doesn't work
when there is another redirection for the same symbol in effect, but that
should not be a concern here (there should be no reason to have an asm
redirection from __mq_timedreceive_time64 to another name, for example).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-25 0:03 ` Joseph Myers
@ 2020-02-25 11:39 ` Lukasz Majewski
2020-02-25 14:36 ` Joseph Myers
0 siblings, 1 reply; 138+ messages in thread
From: Lukasz Majewski @ 2020-02-25 11:39 UTC (permalink / raw)
To: Joseph Myers
Cc: Andreas Schwab, Arnd Bergmann, Florian Weimer, Helmut Grohne,
GNU C Library, Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
Alistair Francis, arcml
[-- Attachment #1: Type: text/plain, Size: 5068 bytes --]
Hi Joseph,
Thanks for the detailed explanation.
> On Mon, 24 Feb 2020, Lukasz Majewski wrote:
>
> > I'm probably not aware of something - but as done in the following
> > patch:
> >
> > https://github.com/lmajewski/y2038_glibc/commit/c96eeb73175961c4ac80fdd3b6adc132805387c9
> >
> > I do need to remove librt_hidden_proto / librt_hidden_def to have
> > proper symbols visible when I do want to use redirections.
>
> You'll need to explain the actual problem you see, because
> lib<name>_hidden_proto / lib<name>_hidden_def are correct for any
> symbol that satisfies both of the following properties: (a) it is
> exported from shared lib<name> (whether at a public symbol version or
> version GLIBC_PRIVATE) and (b) it is also used within the library
> that defines it. They are useless but harmless for other symbols.
>
Lets consider for example __mq_timedsend_time64.
With lib<name>_hidden_def/proto kept (NOT removed as in [1]):
GDB:
__GI___mq_timedsend_time64 [*]
(No build errors, linking with test setup works as expected).
(gdb) bt
#0 __libc_do_syscall ()
at../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
#1 0x76fc2696 in __GI___mq_timedsend_time64 (..)
at../sysdeps/unix/sysv/linux/mq_timedsend.c:33
#2 0x76fc271a in __GI___mq_timedsend (..)
at../sysdeps/unix/sysv/linux/mq_timedsend.c:69
#3 0x76fc2668 in mq_send () at ../sysdeps/unix/sysv/linux/mq_send.c:30
The problem is that __mq_timedsend (32 bit version) is called first -
this means that the redirection for _TIME_BITS==64 (which would call
__mq_timedsend_time64) is not working.
With lib<name>_hidden_def/proto removed (as it is now at [1])
#0 __mq_timedsend_time64 (..) at../sysdeps/unix/sysv/linux/mq_timedsend.c33
#1 0x00402bb0 in test_mq_timedsend_onqueue (q=3)
at test_mq_timedsend.c:25
#2 0x00402f28 in test_mq_timedsend () at test_mq_timedsend.c:130
The redirection for _TIME_BITS==64 works as expected.
The structure of time conversion patches (details in [2]):
@ include/time.h
#if __TIMESIZE == 64
# define __mq_timedsend_time64 __mq_timedsend
#else
# include <bits/types/struct___timespec64.h>
extern int __mq_timedsend_time64 (...);
librt_hidden_proto (__mq_timedsend_time64)
#endif
@sysdeps/unix/sysv/linux/mq_timedsend.c
int __mq_timedsend_time64 (...)
{
}
#if __TIMESIZE != 64
librt_hidden_def (__mq_timedsend_time64)
int __mq_timedsend (..)
{
}
#endif
hidden_def (__mq_timedsend)
weak_alias (__mq_timedsend, mq_timedsend) [**]
hidden_weak (mq_timedsend)
It looks to me like the [**] weak_alias () here is the problem as it
does the aliasing for name, which shall be redirected to
__mq_timedsend_time64.
However, when I remove the line [**] - I do see the error:
| In file included from <command-line>:
| ./../include/libc-symbols.h:552:33: error: '__EI_mq_timedsend'
aliased to undefined symbol '__GI_mq_timedsend'
> lib<name>_hidden_proto / lib<name>_hidden_def always need to be used
> together, and always need to have <name> matching the name of the
> shared library with the symbol. In C code, lib<name>_hidden_proto
> causes the function, for both definition and calls, to be redirected
> to an internal, hidden-visibility alias, while lib<name>_hidden_def
> then adds back the exported name as a non-hidden alias to cause it to
> be exported from the shared library in question.
I was not aware of the lib<name>_hidden_def () role to re-export the
symbols again. Thanks for pointing this out.
>
> It's true that the redirection from lib<name>_hidden_proto doesn't
> work when there is another redirection for the same symbol in effect,
Please correct me if I'm wrong, but from the above code snippet it
looks like we do have (when _TIME_SIZE==64 is defined):
librt_hidden_proto (__mq_timedsend_time64)
librt_hidden_def (__mq_timedsend_time64)
hidden_def (__mq_timedsend)
weak_alias (__mq_timedsend, mq_timedsend)
And in exported headers:
# ifdef __USE_TIME_BITS64
# if defined(__REDIRECT)
extern int __REDIRECT (mq_timedsend, (..),
__mq_timedsend_time64);
# else
# define mq_timedsend __mq_timedsend_time64
# endif
# endif
Unfortunately, the final redirection for mq_timedsend symbol is to
__mq_timedsend, not __mq_timedsend_time64.
> but that should not be a concern here (there should be no reason to
> have an asm redirection from __mq_timedreceive_time64 to another
> name, for example).
>
Question:
[*] - If I may ask - the __GI_ prefix is for glibc internal symbol? And
in the same vein __EI_ is for external one?
Links:
[1] -
https://github.com/lmajewski/y2038_glibc/commit/06fe0342696d7c6fe6115f825052fb07bb609216
[2] - https://patchwork.ozlabs.org/patch/1237939/
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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-25 11:39 ` Lukasz Majewski
@ 2020-02-25 14:36 ` Joseph Myers
2020-02-26 13:18 ` Lukasz Majewski
0 siblings, 1 reply; 138+ messages in thread
From: Joseph Myers @ 2020-02-25 14:36 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Andreas Schwab, Arnd Bergmann, Florian Weimer, Helmut Grohne,
GNU C Library, Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
Alistair Francis, arcml
On Tue, 25 Feb 2020, Lukasz Majewski wrote:
> Lets consider for example __mq_timedsend_time64.
>
> With lib<name>_hidden_def/proto kept (NOT removed as in [1]):
> GDB:
> __GI___mq_timedsend_time64 [*]
>
> (No build errors, linking with test setup works as expected).
What is the actual testcase, and the exact command line used to compile
it?
_TIME_BITS=64 redirection is only relevant for programs built with glibc,
using the installed headers - not for building glibc itself.
lib<name>_hidden_proto is only relevant for building glibc, with its
internal headers - not for programs built with glibc.
If you're talking about a glibc testcase, such tests should be in tests
not tests-internal, so _ISOMAC is defined when they are built, so the
glibc internal headers just wrap the public ones without defining anything
else. In particular, the asm redirections from public headers should be
in effect when tests are compiled, but not the lib<name>_hidden_proto
redirections (but even for internal tests, lib<name>_hidden_proto
shouldn't do anything because the build process knows they are tests not
part of libc).
You should look at the preprocessed source from building the test with
-save-temps and find out why the asm redirection from the public header
isn't being effective (or if it is effective in the .o file for the test,
look at what happens afterwards in glibc). Since lib<name>_hidden_proto
should not be called in the parts of headers included when building a
test, its presence or absence should have no effect on the preprocessed
source of the test.
> hidden_def (__mq_timedsend)
> weak_alias (__mq_timedsend, mq_timedsend) [**]
> hidden_weak (mq_timedsend)
If you have lib<name>_hidden_weak note you also need a corresponding
lib<name>_hidden_proto, for the name of the weak alias. But you probably
don't need to have lib<name>_hidden* for the weak alias at all, just make
sure internal calls use the internal name.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-25 14:36 ` Joseph Myers
@ 2020-02-26 13:18 ` Lukasz Majewski
2020-02-26 14:48 ` Joseph Myers
0 siblings, 1 reply; 138+ messages in thread
From: Lukasz Majewski @ 2020-02-26 13:18 UTC (permalink / raw)
To: Joseph Myers
Cc: Andreas Schwab, Arnd Bergmann, Florian Weimer, Helmut Grohne,
GNU C Library, Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
Alistair Francis, arcml
[-- Attachment #1: Type: text/plain, Size: 4020 bytes --]
Hi Joseph,
> On Tue, 25 Feb 2020, Lukasz Majewski wrote:
>
> > Lets consider for example __mq_timedsend_time64.
> >
> > With lib<name>_hidden_def/proto kept (NOT removed as in [1]):
> > GDB:
> > __GI___mq_timedsend_time64 [*]
> >
> > (No build errors, linking with test setup works as expected).
>
> What is the actual testcase, and the exact command line used to
> compile it?
The test case is a separate program [1] compiled with [2] (the
test_y2038 make target)
The glibc under test is installed on rootfs run by QEMU for ARM.
The lack of redirection, when I keep lib<name>_hidden_proto/
lib<name>_hidden_def for __mq_timedsend_time64, is seen when I debug
with GDB the 'test_y2038' program.
The glibc compiles correctly.
>
> _TIME_BITS=64 redirection is only relevant for programs built with
> glibc, using the installed headers - not for building glibc itself.
>
> lib<name>_hidden_proto is only relevant for building glibc, with its
> internal headers - not for programs built with glibc.
It seems like not removing lib<name>_hidden_proto/ lib<name>_hidden_def
for __mq_timedsend_time64 in glibc sources prevents the redirection on
installed glibc / headers when 'test_y2038' program is run.
>
> If you're talking about a glibc testcase, such tests should be in
> tests not tests-internal, so _ISOMAC is defined when they are built,
> so the glibc internal headers just wrap the public ones without
> defining anything else. In particular, the asm redirections from
> public headers should be in effect when tests are compiled, but not
> the lib<name>_hidden_proto redirections (but even for internal tests,
> lib<name>_hidden_proto shouldn't do anything because the build
> process knows they are tests not part of libc).
Unfortunately, mine Y2038 tests are a set of compiled programs (it is a
'legacy' code) and have nothing in common with glibc test suite.
The workflow is as follows (standard Yocto/OE):
1. Built the glibc and prepare "package" for other recipes.
2. For tests get the glibc "package" as a prerequisite. Use its
exported headers and libraries to build tests. Prepare test "package"
3. Install both above packages to rootfs
4. Run the rootfs with QEMU.
>
> You should look at the preprocessed source from building the test
> with -save-temps and find out why the asm redirection from the public
> header isn't being effective (or if it is effective in the .o file
> for the test, look at what happens afterwards in glibc). Since
> lib<name>_hidden_proto should not be called in the parts of headers
> included when building a test, its presence or absence should have no
> effect on the preprocessed source of the test.
Ok. I will dig the object files and generated temp files.
>
> > hidden_def (__mq_timedsend)
> > weak_alias (__mq_timedsend, mq_timedsend) [**]
> > hidden_weak (mq_timedsend)
>
> If you have lib<name>_hidden_weak note you also need a corresponding
> lib<name>_hidden_proto, for the name of the weak alias. But you
> probably don't need to have lib<name>_hidden* for the weak alias at
> all, just make sure internal calls use the internal name.
As fair as I can tell the weak_alias () is necessary for correct
operation of mq_timedsend when external programs call it.
Glibc internally defines __mq_timedsend (also for archs with
__WORDSIZE==64), but it exports mq_timedsend (and user space programs
call it). One needs an alias (at least a weak one) between mq_timedsend
and __mq_timedsend{_time}. Am I correct?
>
Links:
[1] -
https://github.com/lmajewski/y2038-tests/blob/master/test_mq_timedsend.c#L25
[2] - https://github.com/lmajewski/y2038-tests/blob/master/Makefile
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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-26 13:18 ` Lukasz Majewski
@ 2020-02-26 14:48 ` Joseph Myers
2020-02-26 16:28 ` Lukasz Majewski
0 siblings, 1 reply; 138+ messages in thread
From: Joseph Myers @ 2020-02-26 14:48 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Andreas Schwab, Arnd Bergmann, Florian Weimer, Helmut Grohne,
GNU C Library, Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
Alistair Francis, arcml
On Wed, 26 Feb 2020, Lukasz Majewski wrote:
> > > hidden_def (__mq_timedsend)
> > > weak_alias (__mq_timedsend, mq_timedsend) [**]
> > > hidden_weak (mq_timedsend)
> >
> > If you have lib<name>_hidden_weak note you also need a corresponding
> > lib<name>_hidden_proto, for the name of the weak alias. But you
> > probably don't need to have lib<name>_hidden* for the weak alias at
> > all, just make sure internal calls use the internal name.
>
> As fair as I can tell the weak_alias () is necessary for correct
> operation of mq_timedsend when external programs call it.
I wasn't commenting on the weak_alias call, but on the hidden_weak one.
If you have hidden_weak (mq_timedsend), you also need
lib<name>_hidden_proto (mq_timedsend) in the internal header (and vice
versa, hidden_proto implies you need hidden_weak).
You don't need hidden_weak (mq_timedsend) unless there is an *internal
call to mq_timedsend from within the same library that defines it*.
Since such an internal call could just use __mq_timedsend instead, you
probably don't need hidden_weak / hidden_proto for mq_timedsend.
(If you don't have an internal call to __mq_timedsend, you don't need the
hidden_* for that name either.)
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-26 14:48 ` Joseph Myers
@ 2020-02-26 16:28 ` Lukasz Majewski
0 siblings, 0 replies; 138+ messages in thread
From: Lukasz Majewski @ 2020-02-26 16:28 UTC (permalink / raw)
To: Joseph Myers
Cc: Andreas Schwab, Arnd Bergmann, Florian Weimer, Helmut Grohne,
GNU C Library, Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
Alistair Francis, arcml
[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]
Hi Joseph,
> On Wed, 26 Feb 2020, Lukasz Majewski wrote:
>
> > > > hidden_def (__mq_timedsend)
> > > > weak_alias (__mq_timedsend, mq_timedsend) [**]
> > > > hidden_weak (mq_timedsend)
> > >
> > > If you have lib<name>_hidden_weak note you also need a
> > > corresponding lib<name>_hidden_proto, for the name of the weak
> > > alias. But you probably don't need to have lib<name>_hidden* for
> > > the weak alias at all, just make sure internal calls use the
> > > internal name.
> >
> > As fair as I can tell the weak_alias () is necessary for correct
> > operation of mq_timedsend when external programs call it.
>
> I wasn't commenting on the weak_alias call, but on the hidden_weak
> one.
Ach... indeed - sorry for misunderstanding.
>
> If you have hidden_weak (mq_timedsend), you also need
> lib<name>_hidden_proto (mq_timedsend) in the internal header (and
> vice versa, hidden_proto implies you need hidden_weak).
>
> You don't need hidden_weak (mq_timedsend) unless there is an
> *internal call to mq_timedsend from within the same library that
> defines it*.
>
> Since such an internal call could just use __mq_timedsend instead,
> you probably don't need hidden_weak / hidden_proto for mq_timedsend.
>
> (If you don't have an internal call to __mq_timedsend, you don't need
> the hidden_* for that name either.)
>
Thanks for the explanation.
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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-24 9:00 ` Lukasz Majewski
2020-02-24 9:46 ` Andreas Schwab
@ 2020-02-25 9:03 ` Arnd Bergmann
1 sibling, 0 replies; 138+ messages in thread
From: Arnd Bergmann @ 2020-02-25 9:03 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Vineet Gupta, Alistair Francis, Joseph Myers, Florian Weimer,
GNU C Library, Palmer Dabbelt, Zong Li, Alistair Francis,
Adhemerval Zanella, Maciej W. Rozycki, arcml, debian-arm,
Helmut Grohne
On Mon, Feb 24, 2020 at 10:01 AM Lukasz Majewski <lukma@denx.de> wrote:
> > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@denx.de>
> > wrote:
> > which seems a bug in the test suite. The other two get a segfault
> > that I have not debugged, but I guess this is likely a problem in your
> > patches. Have you seen the same thing?
>
> I only do run the full (including full test suite) glibc-many-build
> (and my Y2038 tests) on the patches which I post to glibc-alpha.
>
> The Y2038 changes I do test manually if they work as expected - but I
> do not run yet the (full) test suites on it, as first _all_ glibc
> functions needs to be converted before _TIME_BITS=64 is added.
>
> The issue is probably with the redirection code. I will look on them
> soon.
Ok, thanks for taking a look, I won't debug this further then,
unless you need help reproducing the issues.
Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
2020-02-20 8:31 ` Arnd Bergmann
2020-02-20 9:37 ` Lukasz Majewski
@ 2020-02-20 16:27 ` Helmut Grohne
2020-03-26 0:25 ` ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t ) Vineet Gupta via Libc-alpha
1 sibling, 1 reply; 138+ messages in thread
From: Helmut Grohne @ 2020-02-20 16:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Lukasz Majewski, Vineet Gupta, Alistair Francis, Joseph Myers,
Florian Weimer, GNU C Library, Palmer Dabbelt, Zong Li,
Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki, arcml,
debian-arm
Hi Arnd,
On Thu, Feb 20, 2020 at 09:31:32AM +0100, Arnd Bergmann wrote:
> > > How do I build a latest RISCV 32-bit kernel + userland - do you have
> > > a buildroot branch somewhere that I can build / test with qemu ?
> >
> > Maybe a bit off topic - there is such QEMU and Yocto/OE based test
> > sandbox for ARM32:
> >
> > https://github.com/lmajewski/meta-y2038
> >
> > (the README provides steps for setup).
>
> (continuing off-topic, with debian-arm and Helmut on Cc)
>
> Would it be possible to take a snapshot of your glibc tree and
> start testing this out with debian-rebootstrap [1]?
This is exacty what rebootstrap is for. You should be able to experiment
with different ABIs without committing to a particular ABI. You can
fiddle with such aspects and then cross build a pile of around 120
Debian packages. That should uncover the most significant problems. You
don't even have to change the GNU triplet. You can just create an
incompatible throw-away port with an existing architecture name as
rebootstrap refuses to reuse any existing binary packages for the host
architecture.
If you want to pursue that route, get in touch with
debian-cross@lists.debian.org or #debian-bootstrap on irc.oftc.net. The
usual route is forking the rebootstrap.git repository. You just hack up
your toolchain modifications an retry the bootstrap from scratch until
you are satisfied. Be prepared to put up with half a day or a day of CPU
time for a single run. Don't hesitate to ask for help if you have
undecipherable build failures. Balint Reczey has done something quite
similar to what you're up to: He attempted creating ports that are
instrumented with sanitizers.
Since I saw arc in the subject, I also threw arc at rebootstrap. Turns
out that glibc 2.30 does not yet cover arc and using unpackaged versions
of glibc is non-trivial for rebootstrap, so I cannot do much about that.
Once arc support is in a released version of glibc, I'd be happy to be
pinged about it.
Helmut
^ permalink raw reply [flat|nested] 138+ messages in thread
* ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
2020-02-20 16:27 ` Helmut Grohne
@ 2020-03-26 0:25 ` Vineet Gupta via Libc-alpha
2020-03-26 5:54 ` Helmut Grohne
0 siblings, 1 reply; 138+ messages in thread
From: Vineet Gupta via Libc-alpha @ 2020-03-26 0:25 UTC (permalink / raw)
To: Helmut Grohne, GNU C Library, arcml, debian-arm
Hi Helmut,
On 2/20/20 8:27 AM, Helmut Grohne wrote:
>
> Since I saw arc in the subject, I also threw arc at rebootstrap. Turns
> out that glibc 2.30 does not yet cover arc and using unpackaged versions
> of glibc is non-trivial for rebootstrap, so I cannot do much about that.
> Once arc support is in a released version of glibc, I'd be happy to be
> pinged about it.
ARC glibc is still in works, but assuming that will happen in near future what
other upstream prerequisites are needed. The obvious ones would be Linux kernel,
gcc, binutils: all 3 of which are supported for ARC. From a quick glance at debian
wiki pages, I presume *bootstrap is mostly done native, so needs qemu ? (full/user
emulation ? And does qemu need to be upstream too ?
Thx,
-Vineet
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
2020-03-26 0:25 ` ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t ) Vineet Gupta via Libc-alpha
@ 2020-03-26 5:54 ` Helmut Grohne
2020-03-26 11:51 ` Alexey Brodkin via Libc-alpha
2020-08-26 14:39 ` Vineet Gupta via Libc-alpha
0 siblings, 2 replies; 138+ messages in thread
From: Helmut Grohne @ 2020-03-26 5:54 UTC (permalink / raw)
To: Vineet Gupta; +Cc: debian-arm, arcml, GNU C Library
Hi Vineet,
On Wed, Mar 25, 2020 at 05:25:58PM -0700, Vineet Gupta wrote:
> ARC glibc is still in works, but assuming that will happen in near future what
> other upstream prerequisites are needed. The obvious ones would be Linux kernel,
> gcc, binutils: all 3 of which are supported for ARC. From a quick glance at debian
> wiki pages, I presume *bootstrap is mostly done native, so needs qemu ? (full/user
> emulation ? And does qemu need to be upstream too ?
Given that I ran into the glibc issue, I can tell that at least
rudimentary arc support support is already available in Debian unstable
for binutils, linux and gcc. (Otherwise, I would not have come as far as
glibc.) Once glibc is in place, work can proceed on the Debian side.
guile, libatomic-ops, libffi, libgpg-error and nspr ususally need a
little upstream support. dpkg, gmp, openssl, and perl usually need
Debian-specific changes. I'd recommend looking into libatomic-ops and
libffi early. The other packages are usually simple.
The aim of rebootstrap is to create a package set for essential +
build-essential using cross builds without using any qemu. Beyond that
point, you'd switch to native building. Unless real hardware is
available, you'd need qemu after the reboostrap phase. Whether you use
full or user emulation is your choice, but I guess that you can speed up
builds using user emulation, because it allows you to mix and match
binaries. When you upstream your qemu is also your choice.
Please get in touch with me once a suitable glibc is packaged for Debian
unstable or experimental. Please use debian-cross@lists.debian.org or
irc.oftc.net #debian-bootstrap at that point. Alternatively, package a
glibc locally (like Arnd did).
Helmut
^ permalink raw reply [flat|nested] 138+ messages in thread
* RE: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
2020-03-26 5:54 ` Helmut Grohne
@ 2020-03-26 11:51 ` Alexey Brodkin via Libc-alpha
2020-03-26 12:24 ` Helmut Grohne
2020-08-26 14:39 ` Vineet Gupta via Libc-alpha
1 sibling, 1 reply; 138+ messages in thread
From: Alexey Brodkin via Libc-alpha @ 2020-03-26 11:51 UTC (permalink / raw)
To: Helmut Grohne
Cc: debian-arm@lists.debian.org, arcml, GNU C Library, Vineet Gupta
Hi Helmut,
> On Wed, Mar 25, 2020 at 05:25:58PM -0700, Vineet Gupta wrote:
> > ARC glibc is still in works, but assuming that will happen in near future what
> > other upstream prerequisites are needed. The obvious ones would be Linux kernel,
> > gcc, binutils: all 3 of which are supported for ARC. From a quick glance at debian
> > wiki pages, I presume *bootstrap is mostly done native, so needs qemu ? (full/user
> > emulation ? And does qemu need to be upstream too ?
>
> Given that I ran into the glibc issue, I can tell that at least
> rudimentary arc support support is already available in Debian unstable
> for binutils, linux and gcc. (Otherwise, I would not have come as far as
> glibc.) Once glibc is in place, work can proceed on the Debian side.
> guile, libatomic-ops, libffi, libgpg-error and nspr ususally need a
> little upstream support. dpkg, gmp, openssl, and perl usually need
> Debian-specific changes. I'd recommend looking into libatomic-ops and
> libffi early. The other packages are usually simple.
I guess almost all of the packages you mentioned already have
needed improvements for ARC.
1. libffi has ARC support since v3.1, see:
https://github.com/libffi/libffi/commit/b082e15091961373c03d10ed0251f619ebb6ed76
2. libgpg-error has ARC support since v1.33, see:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=48c8f8ddfc80
3. nspr has ARC support since v4.1, see:
https://hg.mozilla.org/projects/nspr/rev/cc73b6c7dab2e8053533e1f2c0c23dc721e10b76
And only for "libatomic-ops" & "guile" nothing has been done yet so if there's something
that really needs to be done please let us know.
-Alexey
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
2020-03-26 11:51 ` Alexey Brodkin via Libc-alpha
@ 2020-03-26 12:24 ` Helmut Grohne
2020-03-26 12:53 ` Alexey Brodkin via Libc-alpha
0 siblings, 1 reply; 138+ messages in thread
From: Helmut Grohne @ 2020-03-26 12:24 UTC (permalink / raw)
To: Alexey Brodkin
Cc: debian-arm@lists.debian.org, arcml, GNU C Library, Vineet Gupta
Hi Alexey,
On Thu, Mar 26, 2020 at 11:51:44AM +0000, Alexey Brodkin wrote:
> I guess almost all of the packages you mentioned already have
> needed improvements for ARC.
I didn't mean to imply that anything was missing. I just mentioned those
that usually need work without having checked any.
> 2. libgpg-error has ARC support since v1.33, see:
> http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=48c8f8ddfc80
This is only the native-support. For rebootstrap, we also need cross
build support, i.e. recording the generated lock-obj header (once glibc
is done).
> And only for "libatomic-ops" & "guile" nothing has been done yet so if there's something
> that really needs to be done please let us know.
I suggest that you focus on libatomic-ops then. And on glibc of course.
I guess that the other issues are easily solvable when they arise.
Helmut
^ permalink raw reply [flat|nested] 138+ messages in thread
* RE: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
2020-03-26 12:24 ` Helmut Grohne
@ 2020-03-26 12:53 ` Alexey Brodkin via Libc-alpha
2020-03-26 14:28 ` Helmut Grohne
0 siblings, 1 reply; 138+ messages in thread
From: Alexey Brodkin via Libc-alpha @ 2020-03-26 12:53 UTC (permalink / raw)
To: Helmut Grohne
Cc: GNU C Library, Vineet Gupta, Vineet Gupta,
debian-arm@lists.debian.org, arcml, Claudiu Zissulescu
Hi Helmut,
> > 2. libgpg-error has ARC support since v1.33, see:
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.gnupg.org_cgi-2Dbin_gitweb.cgi-3Fp-
> 3Dlibgpg-2Derror.git-3Ba-3Dcommit-3Bh-
> 3D48c8f8ddfc80&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=_zJyx
> Gdx_-O_dKHjFp6S-2ZXebEcmuHfmUsgpc4uEXA&s=myC306ViTlaxOV8nbOJR8pC74k2lsKmmB1hCGQR0PrE&e=
>
> This is only the native-support. For rebootstrap, we also need cross
> build support, i.e. recording the generated lock-obj header (once glibc
> is done).
>
> > And only for "libatomic-ops" & "guile" nothing has been done yet so if there's something
> > that really needs to be done please let us know.
>
> I suggest that you focus on libatomic-ops then. And on glibc of course.
> I guess that the other issues are easily solvable when they arise.
Sorry for this stupid question but I'm not very familiar with use-cases for
libatomic-ops so would like to get some more clarification on what's needed here.
I know that GCC has quite a few built-ins for atomic ops and we do implement them.
I'm adding our GCC maintainer (Claudiu) in the Cc so he may jump in if needed.
-Alexey
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
2020-03-26 12:53 ` Alexey Brodkin via Libc-alpha
@ 2020-03-26 14:28 ` Helmut Grohne
2020-03-26 19:04 ` Lennart Sorensen via Libc-alpha
0 siblings, 1 reply; 138+ messages in thread
From: Helmut Grohne @ 2020-03-26 14:28 UTC (permalink / raw)
To: Alexey Brodkin
Cc: GNU C Library, Vineet Gupta, Vineet Gupta,
debian-arm@lists.debian.org, arcml, Claudiu Zissulescu
Hi Alexey,
On Thu, Mar 26, 2020 at 12:53:45PM +0000, Alexey Brodkin wrote:
> Sorry for this stupid question but I'm not very familiar with use-cases for
> libatomic-ops so would like to get some more clarification on what's needed here.
>
> I know that GCC has quite a few built-ins for atomic ops and we do implement them.
> I'm adding our GCC maintainer (Claudiu) in the Cc so he may jump in if needed.
One part of the question here is "why do we need libatomic-ops?". The
answer to that is, because libgc uses it and libgc is used by e.g. gcc,
gnutls, guile, and make. Possibly, some of these could be built without
libgc, but this is how they are packaged for Debian at present. Package
dependencies currently say that we need libatomic-ops.
The other part is "what is missing in libatomic-ops"? If you look at a
more recent implementation, such as riscv, you see that it basically
says "trust gcc". So I guess all you need here is an arc-specific
implementation that says "gcc knows what it is doing, use its
primitives".
Given sufficient work, I guess libatomic-ops could be removed in favour
of using the gcc built-ins directly. Not sure whether that'd fly with
libgc upstream though.
So no, this is not a stupid question. Thank you for asking.
Helmut
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
2020-03-26 14:28 ` Helmut Grohne
@ 2020-03-26 19:04 ` Lennart Sorensen via Libc-alpha
0 siblings, 0 replies; 138+ messages in thread
From: Lennart Sorensen via Libc-alpha @ 2020-03-26 19:04 UTC (permalink / raw)
To: Helmut Grohne, Alexey Brodkin, debian-arm@lists.debian.org, arcml,
GNU C Library, Vineet Gupta, Claudiu Zissulescu, Vineet Gupta
On Thu, Mar 26, 2020 at 03:28:36PM +0100, Helmut Grohne wrote:
> One part of the question here is "why do we need libatomic-ops?". The
> answer to that is, because libgc uses it and libgc is used by e.g. gcc,
> gnutls, guile, and make. Possibly, some of these could be built without
> libgc, but this is how they are packaged for Debian at present. Package
> dependencies currently say that we need libatomic-ops.
>
> The other part is "what is missing in libatomic-ops"? If you look at a
> more recent implementation, such as riscv, you see that it basically
> says "trust gcc". So I guess all you need here is an arc-specific
> implementation that says "gcc knows what it is doing, use its
> primitives".
>
> Given sufficient work, I guess libatomic-ops could be removed in favour
> of using the gcc built-ins directly. Not sure whether that'd fly with
> libgc upstream though.
>
> So no, this is not a stupid question. Thank you for asking.
The way I read the details on libatomic is that it provides functions
to implement the things a given architecture can't do with intrinsics
in gcc directly. So on some architectures it does nothing and on others
it implements missing bits for atomic operations.
--
Len Sorensen
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
2020-03-26 5:54 ` Helmut Grohne
2020-03-26 11:51 ` Alexey Brodkin via Libc-alpha
@ 2020-08-26 14:39 ` Vineet Gupta via Libc-alpha
2020-08-26 15:43 ` Helmut Grohne
1 sibling, 1 reply; 138+ messages in thread
From: Vineet Gupta via Libc-alpha @ 2020-08-26 14:39 UTC (permalink / raw)
To: debian-cross@lists.debian.org; +Cc: arcml, Helmut Grohne, GNU C Library
Hi,
On 3/25/20 10:54 PM, Helmut Grohne wrote:
> Hi Vineet,
>
> On Wed, Mar 25, 2020 at 05:25:58PM -0700, Vineet Gupta wrote:
>> ARC glibc is still in works, but assuming that will happen in near future what
>> other upstream prerequisites are needed. The obvious ones would be Linux kernel,
>> gcc, binutils: all 3 of which are supported for ARC. From a quick glance at debian
>> wiki pages, I presume *bootstrap is mostly done native, so needs qemu ? (full/user
>> emulation ? And does qemu need to be upstream too ?
> Given that I ran into the glibc issue, I can tell that at least
> rudimentary arc support support is already available in Debian unstable
> for binutils, linux and gcc. (Otherwise, I would not have come as far as
> glibc.) Once glibc is in place, work can proceed on the Debian side.
> guile, libatomic-ops, libffi, libgpg-error and nspr ususally need a
> little upstream support. dpkg, gmp, openssl, and perl usually need
> Debian-specific changes. I'd recommend looking into libatomic-ops and
> libffi early. The other packages are usually simple.
>
> The aim of rebootstrap is to create a package set for essential +
> build-essential using cross builds without using any qemu. Beyond that
> point, you'd switch to native building. Unless real hardware is
> available, you'd need qemu after the reboostrap phase. Whether you use
> full or user emulation is your choice, but I guess that you can speed up
> builds using user emulation, because it allows you to mix and match
> binaries. When you upstream your qemu is also your choice.
>
> Please get in touch with me once a suitable glibc is packaged for Debian
> unstable or experimental. Please use debian-cross@lists.debian.org or
> irc.oftc.net #debian-bootstrap at that point. Alternatively, package a
> glibc locally (like Arnd did).
Following up as ARC glibc port was merged upstream in 2.32. Can we now give
rebootstrap a spin for ARC Debian enablement.
Thx,
-Vineet
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
2020-08-26 14:39 ` Vineet Gupta via Libc-alpha
@ 2020-08-26 15:43 ` Helmut Grohne
2020-08-26 21:16 ` Aurelien Jarno
0 siblings, 1 reply; 138+ messages in thread
From: Helmut Grohne @ 2020-08-26 15:43 UTC (permalink / raw)
To: Vineet Gupta
Cc: debian-glibc, debian-cross@lists.debian.org, arcml, GNU C Library
Hi Vineet,
On Wed, Aug 26, 2020 at 02:39:53PM +0000, Vineet Gupta wrote:
> Following up as ARC glibc port was merged upstream in 2.32. Can we now give
> rebootstrap a spin for ARC Debian enablement.
That's great news. Unfortunately, it's not that easy yet. rebootstrap
requires the relevant software to be packaged for Debian and the glibc
packaging has only reached 2.31 yet. 2.32 is not even in experimental
yet.
Trying rebootstrap with an experimental glibc is not entirely trivial,
but possible.
Aurelien (Cced via d-glibc@l.d.o), are there plans to upload 2.32 to
experimental anytime soon?
Alternatively, can we segregate the relevant diff between 2.31 and 2.32
and apply it to the unstable package without bumping the version?
Helmut
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
2020-08-26 15:43 ` Helmut Grohne
@ 2020-08-26 21:16 ` Aurelien Jarno
2021-02-24 20:17 ` Vineet Gupta via Libc-alpha
2021-08-21 17:36 ` Aurelien Jarno
0 siblings, 2 replies; 138+ messages in thread
From: Aurelien Jarno @ 2020-08-26 21:16 UTC (permalink / raw)
To: Vineet Gupta, debian-cross@lists.debian.org, GNU C Library, arcml,
debian-glibc
Hi Helmut,
On 2020-08-26 17:43, Helmut Grohne wrote:
> Hi Vineet,
>
> On Wed, Aug 26, 2020 at 02:39:53PM +0000, Vineet Gupta wrote:
> > Following up as ARC glibc port was merged upstream in 2.32. Can we now give
> > rebootstrap a spin for ARC Debian enablement.
>
> That's great news. Unfortunately, it's not that easy yet. rebootstrap
> requires the relevant software to be packaged for Debian and the glibc
> packaging has only reached 2.31 yet. 2.32 is not even in experimental
> yet.
>
> Trying rebootstrap with an experimental glibc is not entirely trivial,
> but possible.
>
> Aurelien (Cced via d-glibc@l.d.o), are there plans to upload 2.32 to
> experimental anytime soon?
No it's not planned soon. glibc 2.32 has removed support for nsl and
rpc, so we first have to do the transition to their replacement. That is
libnsl, libnss-nis and libnss-nisplus for nsl, and rpcsvc-proto and
libtirpc3 for rpc. The nsl transition is in good state, but the packages
are stuck in NEW. We've started to work on the rpc transition, however
there is a lot more work, we have at least ~50 packages that FTBFS and
need to be manually patched to use libtirpc3 instead of the glibc
implementation.
We definitely need to use experimental to test those two transitions and
ask for archive rebuilds, so it's not possible to upload a 2.32 package
there.
> Alternatively, can we segregate the relevant diff between 2.31 and 2.32
> and apply it to the unstable package without bumping the version?
I don't think that's really possible, new ports introduced in version
2.32 will have all the symbol versions set to GLIBC_2.32.
Regards,
Aurelien
PS Helmut: Once libnsl, libnss-nis and libnss-nisplus are out of NEW,
you might want to see if they can be cross-built, and if that impacts
the bootstrap process as the glibc packages are going to depend on those
(in the same way as for the libxcrypt transition).
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
2020-08-26 21:16 ` Aurelien Jarno
@ 2021-02-24 20:17 ` Vineet Gupta via Libc-alpha
2021-02-26 9:47 ` Helmut Grohne
2021-08-21 17:36 ` Aurelien Jarno
1 sibling, 1 reply; 138+ messages in thread
From: Vineet Gupta via Libc-alpha @ 2021-02-24 20:17 UTC (permalink / raw)
To: Vineet Gupta, debian-cross@lists.debian.org, GNU C Library, arcml,
debian-glibc@lists.debian.org, Aurelien Jarno
Hi Helmut, Aurelien
On 8/26/20 2:16 PM, Aurelien Jarno wrote:
> Hi Helmut,
>
> On 2020-08-26 17:43, Helmut Grohne wrote:
>> Hi Vineet,
>>
>> On Wed, Aug 26, 2020 at 02:39:53PM +0000, Vineet Gupta wrote:
>>> Following up as ARC glibc port was merged upstream in 2.32. Can we now give
>>> rebootstrap a spin for ARC Debian enablement.
>> That's great news. Unfortunately, it's not that easy yet. rebootstrap
>> requires the relevant software to be packaged for Debian and the glibc
>> packaging has only reached 2.31 yet. 2.32 is not even in experimental
>> yet.
>>
>> Trying rebootstrap with an experimental glibc is not entirely trivial,
>> but possible.
>>
>> Aurelien (Cced via d-glibc@l.d.o), are there plans to upload 2.32 to
>> experimental anytime soon?
> No it's not planned soon. glibc 2.32 has removed support for nsl and
> rpc, so we first have to do the transition to their replacement. That is
> libnsl, libnss-nis and libnss-nisplus for nsl, and rpcsvc-proto and
> libtirpc3 for rpc. The nsl transition is in good state, but the packages
> are stuck in NEW. We've started to work on the rpc transition, however
> there is a lot more work, we have at least ~50 packages that FTBFS and
> need to be manually patched to use libtirpc3 instead of the glibc
> implementation.
>
> We definitely need to use experimental to test those two transitions and
> ask for archive rebuilds, so it's not possible to upload a 2.32 package
> there.
>
>> Alternatively, can we segregate the relevant diff between 2.31 and 2.32
>> and apply it to the unstable package without bumping the version?
> I don't think that's really possible, new ports introduced in version
> 2.32 will have all the symbol versions set to GLIBC_2.32.
>
> Regards,
> Aurelien
>
>
> PS Helmut: Once libnsl, libnss-nis and libnss-nisplus are out of NEW,
> you might want to see if they can be cross-built, and if that impacts
> the bootstrap process as the glibc packages are going to depend on those
> (in the same way as for the libxcrypt transition).
Checking in to see if things have change since my last posting on this
topic.
Is glibc 2.32 now packaged for debian so we can attempt ARC rebootstrap ?
Thx,
-Vineet
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
2021-02-24 20:17 ` Vineet Gupta via Libc-alpha
@ 2021-02-26 9:47 ` Helmut Grohne
2021-02-26 15:58 ` Vineet Gupta via Libc-alpha
0 siblings, 1 reply; 138+ messages in thread
From: Helmut Grohne @ 2021-02-26 9:47 UTC (permalink / raw)
To: Vineet Gupta
Cc: debian-glibc@lists.debian.org, debian-cross@lists.debian.org,
arcml, GNU C Library, Aurelien Jarno
Hi Vineet,
On Wed, Feb 24, 2021 at 08:17:53PM +0000, Vineet Gupta wrote:
> Checking in to see if things have change since my last posting on this
> topic.
Appreciated. I would have forgotten about arc.
> Is glibc 2.32 now packaged for debian so we can attempt ARC rebootstrap ?
Unfortunately, no. Debian has started freezing in preparating of the
bullseye release. Only up to version 2.31 is packaged and Aurelien seems
a little busy these days. If I recall correctly, 2.32 drops some
backwards compatibility stuff that Debian still relies on $somewhere,
but is transitioning away already. So it's not just dumping 2.32
together with the 2.31 packaging in experimental.
Before that happens, there is little I can do to help. With 2.31, we
still get:
| checking sysdep dirs... configure: error: The arc is not supported.
I'm still interested in supporting the arc bootstrap. Please get back
with me when we can move on.
You can check Debian's glibc version at
https://tracker.debian.org/pkg/glibc at any time in the version column.
Helmut
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
2021-02-26 9:47 ` Helmut Grohne
@ 2021-02-26 15:58 ` Vineet Gupta via Libc-alpha
0 siblings, 0 replies; 138+ messages in thread
From: Vineet Gupta via Libc-alpha @ 2021-02-26 15:58 UTC (permalink / raw)
To: debian-cross@lists.debian.org, GNU C Library, arcml,
debian-glibc@lists.debian.org, Aurelien Jarno
Hi Helmut,
On 2/26/21 1:47 AM, Helmut Grohne wrote:
>
> Unfortunately, no. Debian has started freezing in preparating of the
> bullseye release. Only up to version 2.31 is packaged and Aurelien seems
> a little busy these days. If I recall correctly, 2.32 drops some
> backwards compatibility stuff that Debian still relies on $somewhere,
> but is transitioning away already.
2.32 also brings in 64-bit time_t/offset support (at least the ARC ABI
is) so there might be even more work in rest of ecosystem.
> So it's not just dumping 2.32
> together with the 2.31 packaging in experimental.
>
> Before that happens, there is little I can do to help. With 2.31, we
> still get:
> | checking sysdep dirs... configure: error: The arc is not supported.
At one point you were contemplating diff'ing between glibc 2.31 and 2.32
and trying to apply that to unstable package w/o bumping the version.
But how about we take 2.31 as baseline and use the prio ARC port (same
32-bit time_t ABI) to kick things forward if just as a hack. We would
then be able to shake out any other potential downstream blockers)
> I'm still interested in supporting the arc bootstrap. Please get back
> with me when we can move on.
Thx, that is appreciated.
> You can check Debian's glibc version at
> https://tracker.debian.org/pkg/glibc at any time in the version column.
Noted.
Thx,
-Vineet
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
2020-08-26 21:16 ` Aurelien Jarno
2021-02-24 20:17 ` Vineet Gupta via Libc-alpha
@ 2021-08-21 17:36 ` Aurelien Jarno
1 sibling, 0 replies; 138+ messages in thread
From: Aurelien Jarno @ 2021-08-21 17:36 UTC (permalink / raw)
To: Vineet Gupta, debian-cross@lists.debian.org, GNU C Library, arcml,
debian-glibc
Hi,
On 2020-08-26 23:16, Aurelien Jarno wrote:
> Hi Helmut,
>
> On 2020-08-26 17:43, Helmut Grohne wrote:
> > Hi Vineet,
> >
> > On Wed, Aug 26, 2020 at 02:39:53PM +0000, Vineet Gupta wrote:
> > > Following up as ARC glibc port was merged upstream in 2.32. Can we now give
> > > rebootstrap a spin for ARC Debian enablement.
> >
> > That's great news. Unfortunately, it's not that easy yet. rebootstrap
> > requires the relevant software to be packaged for Debian and the glibc
> > packaging has only reached 2.31 yet. 2.32 is not even in experimental
> > yet.
> >
> > Trying rebootstrap with an experimental glibc is not entirely trivial,
> > but possible.
> >
> > Aurelien (Cced via d-glibc@l.d.o), are there plans to upload 2.32 to
> > experimental anytime soon?
>
> No it's not planned soon. glibc 2.32 has removed support for nsl and
> rpc, so we first have to do the transition to their replacement. That is
> libnsl, libnss-nis and libnss-nisplus for nsl, and rpcsvc-proto and
> libtirpc3 for rpc. The nsl transition is in good state, but the packages
> are stuck in NEW. We've started to work on the rpc transition, however
> there is a lot more work, we have at least ~50 packages that FTBFS and
> need to be manually patched to use libtirpc3 instead of the glibc
> implementation.
>
> We definitely need to use experimental to test those two transitions and
> ask for archive rebuilds, so it's not possible to upload a 2.32 package
> there.
>
Now that the RPC transition is ongoing, I have just uploaded glibc 2.32
to experimental.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-02-12 0:14 ` Alistair Francis
2020-02-12 1:30 ` Joseph Myers
@ 2020-02-12 1:42 ` Vineet Gupta
2020-02-12 12:58 ` Arnd Bergmann
1 sibling, 1 reply; 138+ messages in thread
From: Vineet Gupta @ 2020-02-12 1:42 UTC (permalink / raw)
To: Alistair Francis
Cc: Florian Weimer, GNU C Library, Arnd Bergmann, Palmer Dabbelt,
Zong Li, Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
arcml, Joseph Myers
On 2/11/20 4:14 PM, Alistair Francis wrote:
> On Tue, Feb 11, 2020 at 4:14 PM Vineet Gupta <vineetg76@gmail.com> wrote:
>>> 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..0da3bdeb5d
>>> --- /dev/null
>>> +++ b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
>>
>> I was hoping newer arches could simply use the asm-generic one ?
>
> We need to specify that RV32 uses a 64-bit time_t. The generic ones
> don't do that for 32-bit arches.
Right. It pains to see that each new port (despite using asm-generic syscall ABI)
will have to make their own copy of something so fundamental as typesizes.h where
only a few things will change. The generic file is no longer generic :-(
Oh well !
>>> +/* 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
>>
>> This is orthogonal to time_t but since we are on topic of newer ports, how are you
>> doing this. The asm-generic uapi defines
>>
>> typedef __kernel_long_t __kernel_off_t;
>>
>> and types.h defines
>>
>> typedef __kernel_off_t off_t;
>>
>> And I presume long on RV32 is 32-bits
>
> Can you point me to the code? Last time I looked the kernel used the
> 64-bit versions for the syscalls on RV32.
You are right. I got confused with the types above: asm-generic syscalls on 32-bit
arches use struct stat64 etc which has 64-bit inode. Similarly sys_llseek uses
low/high parts for offset.
>>> +/* Same for ino_t and ino64_t. */
>>> +# define __INO_T_MATCHES_INO64_T 1
I'm surprised that ARC port doesn't define this in glibc, yet we use the
asm-generic syscall interface where this is true. I need to investigate more.
Thx,
-vineet
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-02-12 1:42 ` [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64 Vineet Gupta
@ 2020-02-12 12:58 ` Arnd Bergmann
0 siblings, 0 replies; 138+ messages in thread
From: Arnd Bergmann @ 2020-02-12 12:58 UTC (permalink / raw)
To: Vineet Gupta
Cc: Alistair Francis, Florian Weimer, GNU C Library, Palmer Dabbelt,
Zong Li, Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
arcml, Joseph Myers
On Wed, Feb 12, 2020 at 2:42 AM Vineet Gupta <vineetg76@gmail.com> wrote:
> On 2/11/20 4:14 PM, Alistair Francis wrote:
> > On Tue, Feb 11, 2020 at 4:14 PM Vineet Gupta <vineetg76@gmail.com> wrote:
>
> >>> +/* Same for ino_t and ino64_t. */
> >>> +# define __INO_T_MATCHES_INO64_T 1
>
> I'm surprised that ARC port doesn't define this in glibc, yet we use the
> asm-generic syscall interface where this is true. I need to investigate more.
All 32-bit kernels supported by glibc today define the 64-bit file offset types
(__off64_t, __ino64_t, ...) and a lot of them never had the old 'long' types
(__off_t, __ino_t, ...), but applications can still pick between the two ABIs
when compiling against glibc, see /usr/include/fcntl.h:
#ifndef __off_t_defined
# ifndef __USE_FILE_OFFSET64
typedef __off_t off_t;
# else
typedef __off64_t off_t;
# endif
# define __off_t_defined
#endif
If you use the old types, glibc will do the conversion in the syscall wrappers
on architectures that only have the 64-bit interfaces.
Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-01-12 10:33 ` [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64 Alistair Francis
2020-01-14 12:07 ` Lukasz Majewski
2020-02-12 0:14 ` Vineet Gupta
@ 2020-02-19 0:56 ` Vineet Gupta
2020-02-19 1:03 ` Alistair Francis
2 siblings, 1 reply; 138+ messages in thread
From: Vineet Gupta @ 2020-02-19 0:56 UTC (permalink / raw)
To: Alistair Francis, libc-alpha@sourceware.org
Cc: arnd@arndb.de, adhemerval.zanella@linaro.org, fweimer@redhat.com,
joseph@codesourcery.com, palmerdabbelt@google.com, macro@wdc.com,
zongbox@gmail.com, alistair23@gmail.com, arcml
Hi Alistair,
On 1/12/20 2:33 AM, Alistair Francis wrote:
> diff --git a/sysdeps/unix/sysv/linux/riscv/kernel_stat.h b/sysdeps/unix/sysv/linux/riscv/kernel_stat.h
[snip]...
> +#define STAT_IS_KERNEL_STAT 1
Isn't this irrelevant: seems to be only used for legacy __NR_stat/__NR_stat64
syscalls based__xstat()/__xstat64().
> +
> +#define XSTAT_IS_XSTAT64 1
> +#define STATFS_IS_STATFS64 0
>
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-02-19 0:56 ` Vineet Gupta
@ 2020-02-19 1:03 ` Alistair Francis
2020-02-19 1:31 ` Vineet Gupta
0 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-02-19 1:03 UTC (permalink / raw)
To: Vineet Gupta
Cc: Alistair Francis, libc-alpha@sourceware.org, arnd@arndb.de,
adhemerval.zanella@linaro.org, fweimer@redhat.com,
joseph@codesourcery.com, palmerdabbelt@google.com, macro@wdc.com,
zongbox@gmail.com, arcml
On Tue, Feb 18, 2020 at 4:57 PM Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote:
>
> Hi Alistair,
>
> On 1/12/20 2:33 AM, Alistair Francis wrote:
> > diff --git a/sysdeps/unix/sysv/linux/riscv/kernel_stat.h b/sysdeps/unix/sysv/linux/riscv/kernel_stat.h
>
> [snip]...
>
> > +#define STAT_IS_KERNEL_STAT 1
>
> Isn't this irrelevant: seems to be only used for legacy __NR_stat/__NR_stat64
> syscalls based__xstat()/__xstat64().
Is it? It seems to be used in a few places, including:
sysdeps/unix/sysv/linux/fxstatat.c
sysdeps/unix/sysv/linux/xstatconv.c
Alistair
>
> > +
> > +#define XSTAT_IS_XSTAT64 1
> > +#define STATFS_IS_STATFS64 0
> >
>
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-02-19 1:03 ` Alistair Francis
@ 2020-02-19 1:31 ` Vineet Gupta
2020-02-19 8:30 ` Andreas Schwab
0 siblings, 1 reply; 138+ messages in thread
From: Vineet Gupta @ 2020-02-19 1:31 UTC (permalink / raw)
To: Alistair Francis
Cc: Alistair Francis, libc-alpha@sourceware.org, arnd@arndb.de,
adhemerval.zanella@linaro.org, fweimer@redhat.com,
joseph@codesourcery.com, palmerdabbelt@google.com, macro@wdc.com,
zongbox@gmail.com, arcml
On 2/18/20 5:03 PM, Alistair Francis wrote:
>>> +#define STAT_IS_KERNEL_STAT 1
>> Isn't this irrelevant: seems to be only used for legacy __NR_stat/__NR_stat64
>> syscalls based__xstat()/__xstat64().
> Is it? It seems to be used in a few places, including:
>
> sysdeps/unix/sysv/linux/fxstatat.c
> sysdeps/unix/sysv/linux/xstatconv.c
AFAIK that is not part of the asm-generic syscall ABI which ARC, RISCV et al use !
-Vineet
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-02-19 1:31 ` Vineet Gupta
@ 2020-02-19 8:30 ` Andreas Schwab
2020-02-19 18:42 ` Vineet Gupta
0 siblings, 1 reply; 138+ messages in thread
From: Andreas Schwab @ 2020-02-19 8:30 UTC (permalink / raw)
To: Vineet Gupta
Cc: Alistair Francis, fweimer@redhat.com, libc-alpha@sourceware.org,
arnd@arndb.de, palmerdabbelt@google.com, zongbox@gmail.com,
Alistair Francis, adhemerval.zanella@linaro.org, macro@wdc.com,
arcml, joseph@codesourcery.com
On Feb 19 2020, Vineet Gupta wrote:
> On 2/18/20 5:03 PM, Alistair Francis wrote:
>>>> +#define STAT_IS_KERNEL_STAT 1
>>> Isn't this irrelevant: seems to be only used for legacy __NR_stat/__NR_stat64
>>> syscalls based__xstat()/__xstat64().
>> Is it? It seems to be used in a few places, including:
>>
>> sysdeps/unix/sysv/linux/fxstatat.c
>> sysdeps/unix/sysv/linux/xstatconv.c
>
> AFAIK that is not part of the asm-generic syscall ABI which ARC, RISCV et al use !
The latter is still included by everyone, though.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-02-19 8:30 ` Andreas Schwab
@ 2020-02-19 18:42 ` Vineet Gupta
2020-02-19 23:18 ` Lukasz Majewski
0 siblings, 1 reply; 138+ messages in thread
From: Vineet Gupta @ 2020-02-19 18:42 UTC (permalink / raw)
To: Andreas Schwab
Cc: fweimer@redhat.com, libc-alpha@sourceware.org, arnd@arndb.de,
palmerdabbelt@google.com, zongbox@gmail.com, Alistair Francis,
adhemerval.zanella@linaro.org, macro@wdc.com, Alistair Francis,
arcml, joseph@codesourcery.com
On 2/19/20 12:30 AM, Andreas Schwab wrote:
> On Feb 19 2020, Vineet Gupta wrote:
>
>> On 2/18/20 5:03 PM, Alistair Francis wrote:
>>>>> +#define STAT_IS_KERNEL_STAT 1
>>>> Isn't this irrelevant: seems to be only used for legacy __NR_stat/__NR_stat64
>>>> syscalls based__xstat()/__xstat64().
>>> Is it? It seems to be used in a few places, including:
>>>
>>> sysdeps/unix/sysv/linux/fxstatat.c
>>> sysdeps/unix/sysv/linux/xstatconv.c
>> AFAIK that is not part of the asm-generic syscall ABI which ARC, RISCV et al use !
>
> The latter is still included by everyone, though.
Correct, although it only builds a "dummy" struct for #ifdef STAT_IS_KERNEL_STAT
i.e. for either values of this define - we might as well move that dummy out and
make the rest of code ifndef.
Rest of code in that function __xstat_conv is not meant for asm-generic syscall
ABI anyways.
Thx,
-Vineet
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-02-19 18:42 ` Vineet Gupta
@ 2020-02-19 23:18 ` Lukasz Majewski
2020-02-20 0:26 ` Vineet Gupta
0 siblings, 1 reply; 138+ messages in thread
From: Lukasz Majewski @ 2020-02-19 23:18 UTC (permalink / raw)
To: Vineet Gupta
Cc: Andreas Schwab, fweimer@redhat.com, libc-alpha@sourceware.org,
arnd@arndb.de, palmerdabbelt@google.com, zongbox@gmail.com,
Alistair Francis, adhemerval.zanella@linaro.org, macro@wdc.com,
Alistair Francis, arcml, joseph@codesourcery.com
[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]
Hi Vineet,
> On 2/19/20 12:30 AM, Andreas Schwab wrote:
> > On Feb 19 2020, Vineet Gupta wrote:
> >
> >> On 2/18/20 5:03 PM, Alistair Francis wrote:
> >>>>> +#define STAT_IS_KERNEL_STAT 1
> >>>> Isn't this irrelevant: seems to be only used for legacy
> >>>> __NR_stat/__NR_stat64 syscalls based__xstat()/__xstat64().
> >>> Is it? It seems to be used in a few places, including:
> >>>
> >>> sysdeps/unix/sysv/linux/fxstatat.c
> >>> sysdeps/unix/sysv/linux/xstatconv.c
> >> AFAIK that is not part of the asm-generic syscall ABI which ARC,
> >> RISCV et al use !
> >
> > The latter is still included by everyone, though.
>
> Correct, although it only builds a "dummy" struct for #ifdef
> STAT_IS_KERNEL_STAT i.e. for either values of this define - we might
> as well move that dummy out and make the rest of code ifndef.
>
> Rest of code in that function __xstat_conv is not meant for
> asm-generic syscall ABI anyways.
Please keep in mind that there are some architectures (like 32 bit
ARM), which are NOT using asm-generic API.
Those archs also require support for 64 bit time. That is why Alistair
put the [sg]etitimer conversion code into sysdeps/unix/sysv/linux/
directory.
In that way all eligible archs could reuse the same conversion code.
>
> Thx,
> -Vineet
>
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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-02-19 23:18 ` Lukasz Majewski
@ 2020-02-20 0:26 ` Vineet Gupta
2020-02-20 0:46 ` Joseph Myers
0 siblings, 1 reply; 138+ messages in thread
From: Vineet Gupta @ 2020-02-20 0:26 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Andreas Schwab, fweimer@redhat.com, libc-alpha@sourceware.org,
arnd@arndb.de, palmerdabbelt@google.com, zongbox@gmail.com,
Alistair Francis, adhemerval.zanella@linaro.org, macro@wdc.com,
Alistair Francis, arcml, joseph@codesourcery.com
Hi Lukasz,
On 2/19/20 3:18 PM, Lukasz Majewski wrote:
> Please keep in mind that there are some architectures (like 32 bit
> ARM), which are NOT using asm-generic API.
Right understand that.
> Those archs also require support for 64 bit time. That is why Alistair
> put the [sg]etitimer conversion code into sysdeps/unix/sysv/linux/
> directory.
>
> In that way all eligible archs could reuse the same conversion code.
Do note that the statx syscall to glibc stat64 interworking is already usable for
both cases as it is in sysdeps/unix/sysv/linux/statx_cp.*
Is see that for ARM32, following files are built:
sysdeps/unix/sysv/linux/arm/xstat.c
sysdeps/unix/sysv/linux/arm/fxstat.c
sysdeps/unix/sysv/linux/arm/lxstat.c
sysdeps/unix/sysv/linux/arm/fxstatat.c
sysdeps/unix/sysv/linux/xstat64.c
sysdeps/unix/sysv/linux/fxstat64.c
sysdeps/unix/sysv/linux/lxstat64.c
sysdeps/unix/sysv/linux/fxstatat64.c
My patch will switch the last 4 for ARM as well.
The first 4 will need more work as sym aliasing like
strong_alias (__xstat64, __xstat)
will be needed in those ARM files (which in turn use i386).
Anyhow, let me test my patch and then we can take it from there !
Thx,
-Vineet
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-02-20 0:26 ` Vineet Gupta
@ 2020-02-20 0:46 ` Joseph Myers
2020-02-20 8:24 ` Arnd Bergmann
0 siblings, 1 reply; 138+ messages in thread
From: Joseph Myers @ 2020-02-20 0:46 UTC (permalink / raw)
To: Vineet Gupta
Cc: Lukasz Majewski, Andreas Schwab, fweimer@redhat.com,
libc-alpha@sourceware.org, arnd@arndb.de,
palmerdabbelt@google.com, zongbox@gmail.com, Alistair Francis,
adhemerval.zanella@linaro.org, macro@wdc.com, Alistair Francis,
arcml
On Thu, 20 Feb 2020, Vineet Gupta wrote:
> The first 4 will need more work as sym aliasing like
> strong_alias (__xstat64, __xstat)
>
> will be needed in those ARM files (which in turn use i386).
The situation for Arm is fundamentally different from that for ARC.
For ARC, you only need a single public stat structure (using 64-bit times
and offsets).
For Arm, a third public stat structure will need to be added alongside the
existing two, initially used internally in 64-bit-time stat functions that
aren't exported from glibc, eventually to be used with _TIME_BITS=64 with
the 64-bit-time stat interfaces exported once all the _TIME_BITS=64
interfaces are ready.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-02-20 0:46 ` Joseph Myers
@ 2020-02-20 8:24 ` Arnd Bergmann
2020-02-20 10:28 ` Lukasz Majewski
2020-02-20 14:14 ` Joseph Myers
0 siblings, 2 replies; 138+ messages in thread
From: Arnd Bergmann @ 2020-02-20 8:24 UTC (permalink / raw)
To: Joseph Myers
Cc: Vineet Gupta, Lukasz Majewski, Andreas Schwab, fweimer@redhat.com,
libc-alpha@sourceware.org, palmerdabbelt@google.com,
zongbox@gmail.com, Alistair Francis,
adhemerval.zanella@linaro.org, macro@wdc.com, Alistair Francis,
arcml
On Thu, Feb 20, 2020 at 1:46 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 20 Feb 2020, Vineet Gupta wrote:
>
> > The first 4 will need more work as sym aliasing like
> > strong_alias (__xstat64, __xstat)
> >
> > will be needed in those ARM files (which in turn use i386).
>
> The situation for Arm is fundamentally different from that for ARC.
>
> For ARC, you only need a single public stat structure (using 64-bit times
> and offsets).
>
> For Arm, a third public stat structure will need to be added alongside the
> existing two, initially used internally in 64-bit-time stat functions that
> aren't exported from glibc, eventually to be used with _TIME_BITS=64 with
> the 64-bit-time stat interfaces exported once all the _TIME_BITS=64
> interfaces are ready.
But surely that structure layout would be the same on ARM and ARC
as well as all other 32-bit architectures with _TIME_BITS=64, right?
What's wrong with having a single implementation for the most
recent set of stat syscalls, with the older variants being only compiled
for architectures that need them to support _TIME_BITS=32 and/or
_FILE_OFFSET_BITS=32?
Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-02-20 8:24 ` Arnd Bergmann
@ 2020-02-20 10:28 ` Lukasz Majewski
2020-02-20 14:14 ` Joseph Myers
1 sibling, 0 replies; 138+ messages in thread
From: Lukasz Majewski @ 2020-02-20 10:28 UTC (permalink / raw)
To: Arnd Bergmann, Joseph Myers
Cc: Vineet Gupta, Andreas Schwab, fweimer@redhat.com,
libc-alpha@sourceware.org, palmerdabbelt@google.com,
zongbox@gmail.com, Alistair Francis,
adhemerval.zanella@linaro.org, macro@wdc.com, Alistair Francis,
arcml
[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]
Hi Arnd, Joseph,
> On Thu, Feb 20, 2020 at 1:46 AM Joseph Myers
> <joseph@codesourcery.com> wrote:
> >
> > On Thu, 20 Feb 2020, Vineet Gupta wrote:
> >
> > > The first 4 will need more work as sym aliasing like
> > > strong_alias (__xstat64, __xstat)
> > >
> > > will be needed in those ARM files (which in turn use i386).
> >
> > The situation for Arm is fundamentally different from that for ARC.
> >
> > For ARC, you only need a single public stat structure (using 64-bit
> > times and offsets).
> >
> > For Arm, a third public stat structure will need to be added
> > alongside the existing two, initially used internally in
> > 64-bit-time stat functions that aren't exported from glibc,
> > eventually to be used with _TIME_BITS=64 with the 64-bit-time stat
> > interfaces exported once all the _TIME_BITS=64 interfaces are
> > ready.
>
> But surely that structure layout would be the same on ARM and ARC
> as well as all other 32-bit architectures with _TIME_BITS=64, right?
>
For ARM32 stat case (current):
./io/stat.c -> __xstat -> ./sysdeps/unix/sysv/linux/xstat64.c
and then struct stat64 buf is filled by the kernel.
The generic idea (which requires converting
./sysdeps/unix/sysv/linux/xstat64.c) would be to use statx always in
glibc instead of stat* syscalls (as it is done in
sysdeps/unix/sysv/linux/generic/wordsize-32/xstat64.c)
To do that we do need in-glibc internal new type - namely struct
stat64_time64
which would have always:
__time64_t st_atime; (and st_mtime, st_ctime).
instead of
__time_t st_atime;
and also introduce __cp_stat64_time64_statx along with __cp_stat64_statx
as struct statx inherently support 64 bit time via struct
statx_timestamp even on 32 bit archs.
IMHO using statx as widely as possible in glibc is the easiest way to
convert stat* and friends functions to support Y2038.
> What's wrong with having a single implementation for the most
> recent set of stat syscalls, with the older variants being only
> compiled for architectures that need them to support _TIME_BITS=32
> and/or _FILE_OFFSET_BITS=32?
>
> 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 --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
2020-02-20 8:24 ` Arnd Bergmann
2020-02-20 10:28 ` Lukasz Majewski
@ 2020-02-20 14:14 ` Joseph Myers
1 sibling, 0 replies; 138+ messages in thread
From: Joseph Myers @ 2020-02-20 14:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Vineet Gupta, Lukasz Majewski, Andreas Schwab, fweimer@redhat.com,
libc-alpha@sourceware.org, palmerdabbelt@google.com,
zongbox@gmail.com, Alistair Francis,
adhemerval.zanella@linaro.org, macro@wdc.com, Alistair Francis,
arcml
On Thu, 20 Feb 2020, Arnd Bergmann wrote:
> But surely that structure layout would be the same on ARM and ARC
> as well as all other 32-bit architectures with _TIME_BITS=64, right?
Yes.
> What's wrong with having a single implementation for the most
> recent set of stat syscalls, with the older variants being only compiled
> for architectures that need them to support _TIME_BITS=32 and/or
> _FILE_OFFSET_BITS=32?
The ARC case should be a very simple patch, just changing a few
conditionals so the statx path can be used on an architecture that also
has the old syscalls. No conditionals for whether to build a particular
stat function, or for what that function is called, will be needed. No
conditionals for whether a syscall is available at runtime will be needed,
because at least initially the port will be assuming Linux 5.1 or later.
In the Arm case, the code will need to allow for runtime fallback to old
stat syscalls on kernels without statx, and will need to build the
function using the new layout under a new name. That's a much more
complicated change that can build on top of the ARC change.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* [RFC v6 08/23] RISC-V: Define __NR_* as __NR_*_time64/64 for 32-bit
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (6 preceding siblings ...)
2020-01-12 10:33 ` [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64 Alistair Francis
@ 2020-01-12 10:33 ` Alistair Francis
2020-01-13 13:39 ` Arnd Bergmann
2020-01-12 10:33 ` [RFC v6 09/23] RISC-V: Add support for 32-bit vDSO calls Alistair Francis
` (15 subsequent siblings)
23 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:33 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
---
sysdeps/unix/sysv/linux/riscv/sysdep.h | 73 ++++++++++++++++++++++++++
1 file changed, 73 insertions(+)
diff --git a/sysdeps/unix/sysv/linux/riscv/sysdep.h b/sysdeps/unix/sysv/linux/riscv/sysdep.h
index 201bf9a91b..d030bf0db0 100644
--- a/sysdeps/unix/sysv/linux/riscv/sysdep.h
+++ b/sysdeps/unix/sysv/linux/riscv/sysdep.h
@@ -116,6 +116,79 @@
#include <sysdeps/unix/sysdep.h>
+#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
+
+# ifndef __NR_rt_sigtimedwait
+# define __NR_rt_sigtimedwait __NR_rt_sigtimedwait_time64
+# endif
+
+# ifndef __NR_ppoll
+# define __NR_ppoll __NR_ppoll_time64
+# endif
+
+# ifndef __NR_utimensat
+# define __NR_utimensat __NR_utimensat_time64
+# endif
+
+# ifndef __NR_pselect6
+# define __NR_pselect6 __NR_pselect6_time64
+# endif
+
+# ifndef __NR_recvmmsg
+# define __NR_recvmmsg __NR_recvmmsg_time64
+# endif
+
+# ifndef __NR_semtimedop
+# define __NR_semtimedop __NR_semtimedop_time64
+# endif
+
+# ifndef __NR_mq_timedreceive
+# define __NR_mq_timedreceive __NR_mq_timedreceive_time64
+# endif
+
+# ifndef __NR_mq_timedsend
+# define __NR_mq_timedsend __NR_mq_timedsend_time64
+# endif
+
+# ifndef __NR_timer_gettime
+# define __NR_timer_gettime __NR_timer_gettime64
+# endif
+
+# ifndef __NR_timer_settime
+# define __NR_timer_settime __NR_timer_settime64
+# endif
+
+# ifndef __NR_clock_getres
+# define __NR_clock_getres __NR_clock_getres_time64
+# endif
+
+# ifndef __NR_clock_gettime
+# define __NR_clock_gettime __NR_clock_gettime64
+# endif
+
+# ifndef __NR_timerfd_settime
+# define __NR_timerfd_settime __NR_timerfd_settime64
+# endif
+
+# ifndef __NR_timerfd_gettime
+# define __NR_timerfd_gettime __NR_timerfd_gettime64
+# endif
+
+# ifndef __NR_sched_rr_get_interval
+# define __NR_sched_rr_get_interval __NR_sched_rr_get_interval_time64
+# endif
+
+# ifndef __NR_clock_adjtime
+# define __NR_clock_adjtime __NR_clock_adjtime64
+# endif
+#endif /* __riscv_xlen == 32 */
+
#undef SYS_ify
#define SYS_ify(syscall_name) __NR_##syscall_name
--
2.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* Re: [RFC v6 08/23] RISC-V: Define __NR_* as __NR_*_time64/64 for 32-bit
2020-01-12 10:33 ` [RFC v6 08/23] RISC-V: Define __NR_* as __NR_*_time64/64 for 32-bit Alistair Francis
@ 2020-01-13 13:39 ` Arnd Bergmann
2020-01-14 7:14 ` Alistair Francis
0 siblings, 1 reply; 138+ messages in thread
From: Arnd Bergmann @ 2020-01-13 13:39 UTC (permalink / raw)
To: Alistair Francis
Cc: GNU C Library, Adhemerval Zanella, Florian Weimer, Joseph Myers,
palmerdabbelt, macro, Zong Li, Alistair Francis
On Sun, Jan 12, 2020 at 11:40 AM Alistair Francis
<alistair.francis@wdc.com> wrote:
> +# ifndef __NR_timer_gettime
> +# define __NR_timer_gettime __NR_timer_gettime64
> +# endif
> +
> +# ifndef __NR_timer_settime
> +# define __NR_timer_settime __NR_timer_settime64
> +# endif
> +
> +# ifndef __NR_clock_getres
> +# define __NR_clock_getres __NR_clock_getres_time64
> +# endif
> +
> +# ifndef __NR_clock_gettime
> +# define __NR_clock_gettime __NR_clock_gettime64
> +# endif
What about clock_nanosleep and io_pgetevents?
Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 08/23] RISC-V: Define __NR_* as __NR_*_time64/64 for 32-bit
2020-01-13 13:39 ` Arnd Bergmann
@ 2020-01-14 7:14 ` Alistair Francis
2020-01-14 12:47 ` Arnd Bergmann
0 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-01-14 7:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alistair Francis, GNU C Library, Adhemerval Zanella,
Florian Weimer, Joseph Myers, Palmer Dabbelt, Maciej W. Rozycki,
Zong Li
On Mon, Jan 13, 2020 at 11:39 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Sun, Jan 12, 2020 at 11:40 AM Alistair Francis
> <alistair.francis@wdc.com> wrote:
>
> > +# ifndef __NR_timer_gettime
> > +# define __NR_timer_gettime __NR_timer_gettime64
> > +# endif
> > +
> > +# ifndef __NR_timer_settime
> > +# define __NR_timer_settime __NR_timer_settime64
> > +# endif
> > +
> > +# ifndef __NR_clock_getres
> > +# define __NR_clock_getres __NR_clock_getres_time64
> > +# endif
> > +
> > +# ifndef __NR_clock_gettime
> > +# define __NR_clock_gettime __NR_clock_gettime64
> > +# endif
>
> What about clock_nanosleep and io_pgetevents?
I don't think we need clock_nanosleep as it has it's own C file and as
__ASSUME_TIME64_SYSCALLS is defined we can only ever call the *_time64
version. I think this actually applies to a few of the #defines in
this patch and that they can be removed.
My thoughts (maybe wrongly) with these #defines was to use this to
allow glibc to build and eventually we could remove these. The current
ones are what is required to allow the "old" calls in glibc to
transparently call the "new" ones and as we are using a 64-bit time_t
we can happily just change the syscall to the *_time64 version.
Alistair
>
> Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 08/23] RISC-V: Define __NR_* as __NR_*_time64/64 for 32-bit
2020-01-14 7:14 ` Alistair Francis
@ 2020-01-14 12:47 ` Arnd Bergmann
2020-01-15 7:03 ` Alistair Francis
0 siblings, 1 reply; 138+ messages in thread
From: Arnd Bergmann @ 2020-01-14 12:47 UTC (permalink / raw)
To: Alistair Francis
Cc: Alistair Francis, GNU C Library, Adhemerval Zanella,
Florian Weimer, Joseph Myers, Palmer Dabbelt, Maciej W. Rozycki,
Zong Li
On Tue, Jan 14, 2020 at 8:15 AM Alistair Francis <alistair23@gmail.com> wrote:
> On Mon, Jan 13, 2020 at 11:39 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Sun, Jan 12, 2020 at 11:40 AM Alistair Francis
> > <alistair.francis@wdc.com> wrote:
> >
> > > +# ifndef __NR_timer_gettime
> > > +# define __NR_timer_gettime __NR_timer_gettime64
> > > +# endif
> > > +
> > > +# ifndef __NR_timer_settime
> > > +# define __NR_timer_settime __NR_timer_settime64
> > > +# endif
> > > +
> > > +# ifndef __NR_clock_getres
> > > +# define __NR_clock_getres __NR_clock_getres_time64
> > > +# endif
> > > +
> > > +# ifndef __NR_clock_gettime
> > > +# define __NR_clock_gettime __NR_clock_gettime64
> > > +# endif
> >
> > What about clock_nanosleep and io_pgetevents?
>
> I don't think we need clock_nanosleep as it has it's own C file and as
> __ASSUME_TIME64_SYSCALLS is defined we can only ever call the *_time64
> version. I think this actually applies to a few of the #defines in
> this patch and that they can be removed.
Ok.
> My thoughts (maybe wrongly) with these #defines was to use this to
> allow glibc to build and eventually we could remove these. The current
> ones are what is required to allow the "old" calls in glibc to
> transparently call the "new" ones and as we are using a 64-bit time_t
> we can happily just change the syscall to the *_time64 version.
I would certainly like that better, using the same names for the
system calls as the kernel, and across all 32-bit architectures
seems less confusing for readers, so the fewer redirects are needed,
the better.
Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 08/23] RISC-V: Define __NR_* as __NR_*_time64/64 for 32-bit
2020-01-14 12:47 ` Arnd Bergmann
@ 2020-01-15 7:03 ` Alistair Francis
2020-01-25 20:33 ` Khem Raj
0 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-01-15 7:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alistair Francis, GNU C Library, Adhemerval Zanella,
Florian Weimer, Joseph Myers, Palmer Dabbelt, Maciej W. Rozycki,
Zong Li
On Tue, Jan 14, 2020 at 10:48 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Jan 14, 2020 at 8:15 AM Alistair Francis <alistair23@gmail.com> wrote:
> > On Mon, Jan 13, 2020 at 11:39 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Sun, Jan 12, 2020 at 11:40 AM Alistair Francis
> > > <alistair.francis@wdc.com> wrote:
> > >
> > > > +# ifndef __NR_timer_gettime
> > > > +# define __NR_timer_gettime __NR_timer_gettime64
> > > > +# endif
> > > > +
> > > > +# ifndef __NR_timer_settime
> > > > +# define __NR_timer_settime __NR_timer_settime64
> > > > +# endif
> > > > +
> > > > +# ifndef __NR_clock_getres
> > > > +# define __NR_clock_getres __NR_clock_getres_time64
> > > > +# endif
> > > > +
> > > > +# ifndef __NR_clock_gettime
> > > > +# define __NR_clock_gettime __NR_clock_gettime64
> > > > +# endif
> > >
> > > What about clock_nanosleep and io_pgetevents?
> >
> > I don't think we need clock_nanosleep as it has it's own C file and as
> > __ASSUME_TIME64_SYSCALLS is defined we can only ever call the *_time64
> > version. I think this actually applies to a few of the #defines in
> > this patch and that they can be removed.
>
> Ok.
>
> > My thoughts (maybe wrongly) with these #defines was to use this to
> > allow glibc to build and eventually we could remove these. The current
> > ones are what is required to allow the "old" calls in glibc to
> > transparently call the "new" ones and as we are using a 64-bit time_t
> > we can happily just change the syscall to the *_time64 version.
>
> I would certainly like that better, using the same names for the
> system calls as the kernel, and across all 32-bit architectures
> seems less confusing for readers, so the fewer redirects are needed,
> the better.
Great! In which case I will keep this list as short as possible.
Alistair
>
> Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 08/23] RISC-V: Define __NR_* as __NR_*_time64/64 for 32-bit
2020-01-15 7:03 ` Alistair Francis
@ 2020-01-25 20:33 ` Khem Raj
2020-01-27 8:39 ` Arnd Bergmann
0 siblings, 1 reply; 138+ messages in thread
From: Khem Raj @ 2020-01-25 20:33 UTC (permalink / raw)
To: Alistair Francis, Arnd Bergmann
Cc: Alistair Francis, GNU C Library, Adhemerval Zanella,
Florian Weimer, Joseph Myers, Palmer Dabbelt, Maciej W. Rozycki,
Zong Li
On 1/14/20 11:03 PM, Alistair Francis wrote:
> On Tue, Jan 14, 2020 at 10:48 PM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Tue, Jan 14, 2020 at 8:15 AM Alistair Francis <alistair23@gmail.com> wrote:
>>> On Mon, Jan 13, 2020 at 11:39 PM Arnd Bergmann <arnd@arndb.de> wrote:
>>>> On Sun, Jan 12, 2020 at 11:40 AM Alistair Francis
>>>> <alistair.francis@wdc.com> wrote:
>>>>
>>>>> +# ifndef __NR_timer_gettime
>>>>> +# define __NR_timer_gettime __NR_timer_gettime64
>>>>> +# endif
>>>>> +
>>>>> +# ifndef __NR_timer_settime
>>>>> +# define __NR_timer_settime __NR_timer_settime64
>>>>> +# endif
>>>>> +
>>>>> +# ifndef __NR_clock_getres
>>>>> +# define __NR_clock_getres __NR_clock_getres_time64
>>>>> +# endif
>>>>> +
>>>>> +# ifndef __NR_clock_gettime
>>>>> +# define __NR_clock_gettime __NR_clock_gettime64
>>>>> +# endif
>>>>
>>>> What about clock_nanosleep and io_pgetevents?
>>>
>>> I don't think we need clock_nanosleep as it has it's own C file and as
>>> __ASSUME_TIME64_SYSCALLS is defined we can only ever call the *_time64
>>> version. I think this actually applies to a few of the #defines in
>>> this patch and that they can be removed.
>>
>> Ok.
>>
>>> My thoughts (maybe wrongly) with these #defines was to use this to
>>> allow glibc to build and eventually we could remove these. The current
>>> ones are what is required to allow the "old" calls in glibc to
>>> transparently call the "new" ones and as we are using a 64-bit time_t
>>> we can happily just change the syscall to the *_time64 version.
>>
>> I would certainly like that better, using the same names for the
>> system calls as the kernel, and across all 32-bit architectures
>> seems less confusing for readers, so the fewer redirects are needed,
>> the better.
>
> Great! In which case I will keep this list as short as possible.
>
There is userspace code like [1] which expects SYS_futex
These overrides do not end up in usr/include/bits/syscall-32.h
so it fails to compile
src/xshmfence_futex.h:58:17: error: use of undeclared identifier
'SYS_futex'; did you mean 'sys_futex'?
return syscall(SYS_futex, addr1, op, val1, timeout, addr2, val3);
^~~~~~~~~
I wonder if __NR_futex and other aliases here should be exposed to
userspace?
[1]
https://github.com/freedesktop/libxshmfence/blob/master/src/xshmfence_futex.h#L55-L58
> Alistair
>
>>
>> Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 08/23] RISC-V: Define __NR_* as __NR_*_time64/64 for 32-bit
2020-01-25 20:33 ` Khem Raj
@ 2020-01-27 8:39 ` Arnd Bergmann
2020-01-27 10:02 ` Florian Weimer
0 siblings, 1 reply; 138+ messages in thread
From: Arnd Bergmann @ 2020-01-27 8:39 UTC (permalink / raw)
To: Khem Raj
Cc: Alistair Francis, Alistair Francis, GNU C Library,
Adhemerval Zanella, Florian Weimer, Joseph Myers, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Sat, Jan 25, 2020 at 9:33 PM Khem Raj <raj.khem@gmail.com> wrote:
> On 1/14/20 11:03 PM, Alistair Francis wrote:
>
> There is userspace code like [1] which expects SYS_futex
> These overrides do not end up in usr/include/bits/syscall-32.h
> so it fails to compile
>
> src/xshmfence_futex.h:58:17: error: use of undeclared identifier
> 'SYS_futex'; did you mean 'sys_futex'?
> return syscall(SYS_futex, addr1, op, val1, timeout, addr2, val3);
> ^~~~~~~~~
>
> I wonder if __NR_futex and other aliases here should be exposed to
> userspace?
Please don't, that just makes it harder for the other ports to find
these instances and fix them in a portable way.
Any source code reference to a low-level system call that passes
a time32 type needs to be handled roughly like this:
typedef unsigned int __u32;
#if defined(__x86_64__) && defined(__ILP32__)
typedef long long __kernel_long_t;
#else
typedef long __kernel_long_t;
#endif
typedef __kernel_long_t __kernel_old_time_t;
struct __kernel_old_timespec {
__kernel_long_t tv_sec;
__kernel_long_t tv_nsec;
};
typedef long long __kernel_time64_t;
struct __kernel_timespec {
__kernel_time64_t tv_sec;
long long tv_nsec;
};
static inline long __kernel_futex_time64(__u32 * uaddr, int op, __u32 val,
struct __kernel_timespec *utime,
__u32 * uaddr2, __u32 val3)
{
#ifdef __NR_futex_time64
return syscall(__NR_futex_time64, uaddr, op, val, utime, uaddr2, val3);
#else
errno = -ENOSYS;
return -1;
#endif
}
static inline long __kernel_futex_old(__u32 * uaddr, int op, __u32 val,
struct __kernel_old_timespec *utime,
__u32 * uaddr2, __u32 val3)
{
#ifdef __NR_futex
return syscall(__NR_futex, uaddr, op, val, utime, uaddr2, val3);
#else
errno = -ENOSYS;
return -1;
#endif
}
static inline long __kernel_futex(__u32 *uaddr, int op, __u32 val,
struct timespec *utime,
__u32 *uaddr2, __u32 val3)
{
long ret;
if (sizeof(time_t) > sizeof(__kernel_long_t)) {
if (utime) {
struct __kernel_timespec ts = {
.tv_sec = utime->tv_sec,.tv_nsec =
utime->tv_nsec,
};
ret = __kernel_futex_time64(uaddr, op, val, &ts,
uaddr, val3);
} else {
ret = __kernel_futex_time64(uaddr, op, val, NULL,
uaddr, val3);
}
if (ret != -1 || errno != -ENOSYS)
return ret;
}
if (utime) {
struct __kernel_timespec ts = {
.tv_sec = utime->tv_sec,.tv_nsec = utime->tv_nsec,
};
return __kernel_futex_old(uaddr, op, val, &ts, uaddr,
val3);
}
return __kernel_futex_old(uaddr, op, val, NULL, uaddr, val3);
}
I'm not sure if this covers all corner cases (or even works correctly
at all), but I'm fairly sure that anything simpler would break on some
configurations.
The code above uses the identifiers from the kernel namespace,
and this is how we might decide to distribute it along with the kernel
headers. If applications want to ship their own copy, they might
need to define their own types or require a very recent version of the
kernel headers, as __kernel_old_timespec was only added in linux-5.5
(the older headers just define 'timespec' which conflicts with the libc
type of the same name and cannot be included here at all).
I would like to actually provide automatically generated stubs like
the above from kernel headers, but that clearly requires more
discussion and some more work on turning
include/uapi/asm-generic/unistd.h into machine-readable format
first.
An alternative would be for all C libraries to start providing a futex()
wrapper and a way to identify whether it exists, then the applications
can largely start using that one on all architectures, and fall back to
the time32 version when building against an older libc.
Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 08/23] RISC-V: Define __NR_* as __NR_*_time64/64 for 32-bit
2020-01-27 8:39 ` Arnd Bergmann
@ 2020-01-27 10:02 ` Florian Weimer
2020-01-27 13:11 ` Arnd Bergmann
0 siblings, 1 reply; 138+ messages in thread
From: Florian Weimer @ 2020-01-27 10:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Khem Raj, Alistair Francis, Alistair Francis, GNU C Library,
Adhemerval Zanella, Joseph Myers, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
* Arnd Bergmann:
> On Sat, Jan 25, 2020 at 9:33 PM Khem Raj <raj.khem@gmail.com> wrote:
>> On 1/14/20 11:03 PM, Alistair Francis wrote:
>>
>> There is userspace code like [1] which expects SYS_futex
>> These overrides do not end up in usr/include/bits/syscall-32.h
>> so it fails to compile
>>
>> src/xshmfence_futex.h:58:17: error: use of undeclared identifier
>> 'SYS_futex'; did you mean 'sys_futex'?
>> return syscall(SYS_futex, addr1, op, val1, timeout, addr2, val3);
>> ^~~~~~~~~
>>
>> I wonder if __NR_futex and other aliases here should be exposed to
>> userspace?
>
> Please don't, that just makes it harder for the other ports to find
> these instances and fix them in a portable way.
>
> Any source code reference to a low-level system call that passes
> a time32 type needs to be handled roughly like this:
>
> typedef unsigned int __u32;
> #if defined(__x86_64__) && defined(__ILP32__)
> typedef long long __kernel_long_t;
> #else
> typedef long __kernel_long_t;
> #endif
Is this the type that glibc and some others call register_t? I think
some MIPS targets also need a special definition for it.
> typedef __kernel_long_t __kernel_old_time_t;
> struct __kernel_old_timespec {
> __kernel_long_t tv_sec;
> __kernel_long_t tv_nsec;
> };
> typedef long long __kernel_time64_t;
> struct __kernel_timespec {
> __kernel_time64_t tv_sec;
> long long tv_nsec;
> };
Who is going to provide these types?
If we put it into glibc headers, we should not use the __kernel_*
prefix.
> static inline long __kernel_futex_time64(__u32 * uaddr, int op, __u32 val,
> struct __kernel_timespec *utime,
> __u32 * uaddr2, __u32 val3)
> {
> #ifdef __NR_futex_time64
> return syscall(__NR_futex_time64, uaddr, op, val, utime, uaddr2, val3);
> #else
> errno = -ENOSYS;
> return -1;
> #endif
> }
>
> static inline long __kernel_futex_old(__u32 * uaddr, int op, __u32 val,
> struct __kernel_old_timespec *utime,
> __u32 * uaddr2, __u32 val3)
> {
> #ifdef __NR_futex
> return syscall(__NR_futex, uaddr, op, val, utime, uaddr2, val3);
> #else
> errno = -ENOSYS;
> return -1;
> #endif
>
> }
Ah better design would split the operations that need timeouts from
those which do not, so that only code that actually uses timeouts needs
porting. This avoids the type-polymorphic val2/utime argument.
> The code above uses the identifiers from the kernel namespace,
> and this is how we might decide to distribute it along with the kernel
> headers. If applications want to ship their own copy, they might
> need to define their own types or require a very recent version of the
> kernel headers, as __kernel_old_timespec was only added in linux-5.5
> (the older headers just define 'timespec' which conflicts with the libc
> type of the same name and cannot be included here at all).
Even for the kernel, __kernel_* prefixes are awkward because the old
type variants are almost exclusively userspace constructs.
> An alternative would be for all C libraries to start providing a futex()
> wrapper and a way to identify whether it exists, then the applications
> can largely start using that one on all architectures, and fall back to
> the time32 version when building against an older libc.
Yes, I think this is the right direction. In theory, it is possible to
use GCC extensions to implement overloads. But I tried to do that for
fcntl once, and the macros are rather unwieldy. Furthermore, C++ neds a
different implementation.
Thanks,
Florian
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 08/23] RISC-V: Define __NR_* as __NR_*_time64/64 for 32-bit
2020-01-27 10:02 ` Florian Weimer
@ 2020-01-27 13:11 ` Arnd Bergmann
2020-01-27 13:17 ` Florian Weimer
0 siblings, 1 reply; 138+ messages in thread
From: Arnd Bergmann @ 2020-01-27 13:11 UTC (permalink / raw)
To: Florian Weimer
Cc: Khem Raj, Alistair Francis, Alistair Francis, GNU C Library,
Adhemerval Zanella, Joseph Myers, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Mon, Jan 27, 2020 at 11:02 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Arnd Bergmann:
>
> > On Sat, Jan 25, 2020 at 9:33 PM Khem Raj <raj.khem@gmail.com> wrote:
> >> On 1/14/20 11:03 PM, Alistair Francis wrote:
> >>
> >> There is userspace code like [1] which expects SYS_futex
> >> These overrides do not end up in usr/include/bits/syscall-32.h
> >> so it fails to compile
> >>
> >> src/xshmfence_futex.h:58:17: error: use of undeclared identifier
> >> 'SYS_futex'; did you mean 'sys_futex'?
> >> return syscall(SYS_futex, addr1, op, val1, timeout, addr2, val3);
> >> ^~~~~~~~~
> >>
> >> I wonder if __NR_futex and other aliases here should be exposed to
> >> userspace?
> >
> > Please don't, that just makes it harder for the other ports to find
> > these instances and fix them in a portable way.
> >
> > Any source code reference to a low-level system call that passes
> > a time32 type needs to be handled roughly like this:
> >
> > typedef unsigned int __u32;
> > #if defined(__x86_64__) && defined(__ILP32__)
> > typedef long long __kernel_long_t;
> > #else
> > typedef long __kernel_long_t;
> > #endif
>
> Is this the type that glibc and some others call register_t? I think
> some MIPS targets also need a special definition for it.
No, this is the type that is only different on x32, mips n32
also uses the regular syscall ABI.
> > typedef __kernel_long_t __kernel_old_time_t;
> > struct __kernel_old_timespec {
> > __kernel_long_t tv_sec;
> > __kernel_long_t tv_nsec;
> > };
> > typedef long long __kernel_time64_t;
> > struct __kernel_timespec {
> > __kernel_time64_t tv_sec;
> > long long tv_nsec;
> > };
>
> Who is going to provide these types?
>
> If we put it into glibc headers, we should not use the __kernel_*
> prefix.
I used the types from the existing kernel headers here to not have
to come up with a new naming scheme. If we end up providing the
wrappers from the kernel, then these are the types that should be
used. If glibc ends up providing a futex implementation, that
would clearly use the glibc provided types on the interface and
hide the implementation details. If we make the inline version a
standalone header that can be included in applications under
a permissive license, then all the identifiers should probably be
renamed to something that doesn't conflict with either kernel or
glibc.
> > static inline long __kernel_futex_time64(__u32 * uaddr, int op, __u32 val,
> > struct __kernel_timespec *utime,
> > __u32 * uaddr2, __u32 val3)
> > {
> > #ifdef __NR_futex_time64
> > return syscall(__NR_futex_time64, uaddr, op, val, utime, uaddr2, val3);
> > #else
> > errno = -ENOSYS;
> > return -1;
> > #endif
> > }
> >
> > static inline long __kernel_futex_old(__u32 * uaddr, int op, __u32 val,
> > struct __kernel_old_timespec *utime,
> > __u32 * uaddr2, __u32 val3)
> > {
> > #ifdef __NR_futex
> > return syscall(__NR_futex, uaddr, op, val, utime, uaddr2, val3);
> > #else
> > errno = -ENOSYS;
> > return -1;
> > #endif
> >
> > }
>
> Ah better design would split the operations that need timeouts from
> those which do not, so that only code that actually uses timeouts needs
> porting. This avoids the type-polymorphic val2/utime argument.
I just realized that my version above is completely broken for the
'op' values that pass an integer instead of a pointer, so I agree
this has to be changed in some form that understands the difference
between timeout and val2 passing. :(
My hope was that we can stay close to the in-kernel types for the
prototypes. If we actually autogenerate a header file from the kernel
for all system calls that would help ensure that the prototype that user
space sees is exactly the same one that the kernel sees.
It would almost work by just defining a futex function locally as either
__kernel_futex_time64() or __kernel_futex_old() above based on
sizeof(time_t), but it breaks if anyone ever tries to support the resulting
binary with time64 support on an old kernel.
Having either individual wrappers per futex-op, or a wrapper that
does the conversion based on a switch(op) {} would solve that, but
both have the downside of not working with additional values of
'op' that might be added later.
> > The code above uses the identifiers from the kernel namespace,
> > and this is how we might decide to distribute it along with the kernel
> > headers. If applications want to ship their own copy, they might
> > need to define their own types or require a very recent version of the
> > kernel headers, as __kernel_old_timespec was only added in linux-5.5
> > (the older headers just define 'timespec' which conflicts with the libc
> > type of the same name and cannot be included here at all).
>
> Even for the kernel, __kernel_* prefixes are awkward because the old
> type variants are almost exclusively userspace constructs.
The __kernel_ prefix was always just intended to provide a namespace
for things that may be defined differently from user space and is unlikely
to cause conflicts. It was first added in linux-1.3.79 for basic types
[https://lkml.org/lkml/1996/3/26/68].
> > An alternative would be for all C libraries to start providing a futex()
> > wrapper and a way to identify whether it exists, then the applications
> > can largely start using that one on all architectures, and fall back to
> > the time32 version when building against an older libc.
>
> Yes, I think this is the right direction. In theory, it is possible to
> use GCC extensions to implement overloads. But I tried to do that for
> fcntl once, and the macros are rather unwieldy. Furthermore, C++ neds a
> different implementation.
What is the problem with using a plain uintptr_t or struct timespec* and
requiring callers to add a cast? Is this just a matter of ugly calling
conventions, or are there cases where it causes bigger problems?
Would it help to have the libc futex wrapper take seven arguments with
separate timeout and val2 arguments, and requiring at least one of them
to be 0 or NULL? I think the only reason for the awkward interface in the
kernel is that a syscall with seven arguments would require passing
a structure on most architectures.
Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 08/23] RISC-V: Define __NR_* as __NR_*_time64/64 for 32-bit
2020-01-27 13:11 ` Arnd Bergmann
@ 2020-01-27 13:17 ` Florian Weimer
2020-01-27 14:08 ` Arnd Bergmann
0 siblings, 1 reply; 138+ messages in thread
From: Florian Weimer @ 2020-01-27 13:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Khem Raj, Alistair Francis, Alistair Francis, GNU C Library,
Adhemerval Zanella, Joseph Myers, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
* Arnd Bergmann:
> What is the problem with using a plain uintptr_t or struct timespec* and
> requiring callers to add a cast? Is this just a matter of ugly calling
> conventions, or are there cases where it causes bigger problems?
The problem with casts is that they make code compile which uses the
wrong timespec type. Old 32-bit ports will have at least three of them,
and we should provide as much guidance as possible to programmers to get
this right. If we require them to write casts, I don't think we can
achieve that.
> Would it help to have the libc futex wrapper take seven arguments with
> separate timeout and val2 arguments, and requiring at least one of them
> to be 0 or NULL? I think the only reason for the awkward interface in the
> kernel is that a syscall with seven arguments would require passing
> a structure on most architectures.
I hope that nowadays, we'd just add separate system calls instead of
multiplexers (even though futex_time64 doesn't give much hope). Then
the different operations can use whatever argument types they need.
Thanks,
Florian
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 08/23] RISC-V: Define __NR_* as __NR_*_time64/64 for 32-bit
2020-01-27 13:17 ` Florian Weimer
@ 2020-01-27 14:08 ` Arnd Bergmann
0 siblings, 0 replies; 138+ messages in thread
From: Arnd Bergmann @ 2020-01-27 14:08 UTC (permalink / raw)
To: Florian Weimer
Cc: Khem Raj, Alistair Francis, Alistair Francis, GNU C Library,
Adhemerval Zanella, Joseph Myers, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Mon, Jan 27, 2020 at 2:17 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Arnd Bergmann:
>
> > What is the problem with using a plain uintptr_t or struct timespec* and
> > requiring callers to add a cast? Is this just a matter of ugly calling
> > conventions, or are there cases where it causes bigger problems?
>
> The problem with casts is that they make code compile which uses the
> wrong timespec type. Old 32-bit ports will have at least three of them,
> and we should provide as much guidance as possible to programmers to get
> this right. If we require them to write casts, I don't think we can
> achieve that.
I see, that is definitely a problem if callers mix the kernel types with the
glibc types, even if glibc only provides a single (conditional) definition of
struct timespec in its user-facing headers.
> > Would it help to have the libc futex wrapper take seven arguments with
> > separate timeout and val2 arguments, and requiring at least one of them
> > to be 0 or NULL? I think the only reason for the awkward interface in the
> > kernel is that a syscall with seven arguments would require passing
> > a structure on most architectures.
>
> I hope that nowadays, we'd just add separate system calls instead of
> multiplexers (even though futex_time64 doesn't give much hope). Then
> the different operations can use whatever argument types they need.
I think that is the general trend, but for futex_time64() the goal was to
stay close to the existing futex() despite its problems. In case of
io_uring() and fs{mount,config,mount,pick}() we fortunately avoided
adding new multiplexers.
Coming back to futex, do you think this would work in a libc header?
/* plain kernel syscalls */
extern inline int __futex_time64(int *uaddr, int futex_op, int val,
const struct __timespec64 *timeout,
int *uaddr2, int val3);
extern inline int __futex_old(int *uaddr, int futex_op, int val,
const struct __timespec_old *timeout,
int *uaddr2, int val3);
/* typesafe wrapper, could be inline or out of line */
static __inline int
futex(int *uaddr, int futex_op, int val,
int val2, int *uaddr2, int val3,
const struct timespec *timeout)
{
if (sizeof(time_t) > sizeof(long)) {
int ret;
if (!timeout)
return futex_time64(uaddr, futex_op, val,
val2, uaddr2, val3);
ret = futex_time64(uaddr, futex_op, val, val2, uaddr2, val3);
if (ret == -1 && errno = -ENOSYS) {
int ts[2] = { timeout.tv_sec, timeout.tv_nsec };
return futex_old(uaddr, futex_op, (void
*)ts, val2, uaddr2, val3);
}
}
if (!timeout)
return futex_old(uaddr, futex_op, val, val2, uaddr2, val3);
return futex_old(uaddr, futex_op, (void *)timeout, val2, uaddr2, val3);
}
That would be roughly as efficient as the call to syscall() but do the
right thing in all cases, and not require adding an unsafe dummy
__NR_futex definition.
Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread
* [RFC v6 09/23] RISC-V: Add support for 32-bit vDSO calls
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (7 preceding siblings ...)
2020-01-12 10:33 ` [RFC v6 08/23] RISC-V: Define __NR_* as __NR_*_time64/64 for 32-bit Alistair Francis
@ 2020-01-12 10:33 ` Alistair Francis
2020-01-13 13:33 ` Arnd Bergmann
2020-01-12 10:33 ` [RFC v6 10/23] RISC-V: Add socket-constants.h for RV32 Alistair Francis
` (14 subsequent siblings)
23 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:33 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
---
sysdeps/unix/sysv/linux/riscv/sysdep.h | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/sysdeps/unix/sysv/linux/riscv/sysdep.h b/sysdeps/unix/sysv/linux/riscv/sysdep.h
index d030bf0db0..b02a5c30f6 100644
--- a/sysdeps/unix/sysv/linux/riscv/sysdep.h
+++ b/sysdeps/unix/sysv/linux/riscv/sysdep.h
@@ -194,14 +194,23 @@
#ifndef __ASSEMBLER__
-# define VDSO_NAME "LINUX_4.15"
-# define VDSO_HASH 182943605
+# if __riscv_xlen == 32
+# define VDSO_NAME "LINUX_5.4"
+# define VDSO_HASH 61765876
/* List of system calls which are supported as vsyscalls. */
-# define HAVE_CLOCK_GETRES64_VSYSCALL "__vdso_clock_getres"
-# define HAVE_CLOCK_GETTIME64_VSYSCALL "__vdso_clock_gettime"
-# define HAVE_GETTIMEOFDAY_VSYSCALL "__vdso_gettimeofday"
-# define HAVE_GETCPU_VSYSCALL "__vdso_getcpu"
+# define HAVE_CLOCK_GETTIME64_VSYSCALL "__vdso_clock_gettime64"
+# define HAVE_GETCPU_VSYSCALL "__vdso_getcpu"
+# else
+# define VDSO_NAME "LINUX_4.15"
+# define VDSO_HASH 182943605
+
+/* List of system calls which are supported as vsyscalls. */
+# define HAVE_CLOCK_GETRES64_VSYSCALL "__vdso_clock_getres"
+# define HAVE_CLOCK_GETTIME64_VSYSCALL "__vdso_clock_gettime"
+# define HAVE_GETTIMEOFDAY_VSYSCALL "__vdso_gettimeofday"
+# define HAVE_GETCPU_VSYSCALL "__vdso_getcpu"
+# endif
/* Define a macro which expands into the inline wrapper code for a system
call. */
--
2.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* Re: [RFC v6 09/23] RISC-V: Add support for 32-bit vDSO calls
2020-01-12 10:33 ` [RFC v6 09/23] RISC-V: Add support for 32-bit vDSO calls Alistair Francis
@ 2020-01-13 13:33 ` Arnd Bergmann
2020-01-14 7:23 ` Alistair Francis
0 siblings, 1 reply; 138+ messages in thread
From: Arnd Bergmann @ 2020-01-13 13:33 UTC (permalink / raw)
To: Alistair Francis
Cc: GNU C Library, Adhemerval Zanella, Florian Weimer, Joseph Myers,
palmerdabbelt, macro, Zong Li, Alistair Francis
On Sun, Jan 12, 2020 at 11:40 AM Alistair Francis
<alistair.francis@wdc.com> wrote:
> +# if __riscv_xlen == 32
> +# define VDSO_NAME "LINUX_5.4"
> +# define VDSO_HASH 61765876
> +# define HAVE_CLOCK_GETTIME64_VSYSCALL "__vdso_clock_gettime64"
> +# define HAVE_GETCPU_VSYSCALL "__vdso_getcpu"
Mainline linux doesn't have these yet on risc-v. I assume you have
patches to add them?
Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 09/23] RISC-V: Add support for 32-bit vDSO calls
2020-01-13 13:33 ` Arnd Bergmann
@ 2020-01-14 7:23 ` Alistair Francis
0 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-14 7:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alistair Francis, GNU C Library, Adhemerval Zanella,
Florian Weimer, Joseph Myers, Palmer Dabbelt, Maciej W. Rozycki,
Zong Li
On Mon, Jan 13, 2020 at 11:33 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Sun, Jan 12, 2020 at 11:40 AM Alistair Francis
> <alistair.francis@wdc.com> wrote:
> > +# if __riscv_xlen == 32
> > +# define VDSO_NAME "LINUX_5.4"
> > +# define VDSO_HASH 61765876
>
> > +# define HAVE_CLOCK_GETTIME64_VSYSCALL "__vdso_clock_gettime64"
> > +# define HAVE_GETCPU_VSYSCALL "__vdso_getcpu"
>
> Mainline linux doesn't have these yet on risc-v. I assume you have
> patches to add them?
No... I don't. I just assumed these were supported. I will drop this.
Alistair
>
> Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread
* [RFC v6 10/23] RISC-V: Add socket-constants.h for RV32
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (8 preceding siblings ...)
2020-01-12 10:33 ` [RFC v6 09/23] RISC-V: Add support for 32-bit vDSO calls Alistair Francis
@ 2020-01-12 10:33 ` Alistair Francis
2020-01-12 10:34 ` [RFC v6 11/23] RISC-V: Support dynamic loader for the 32-bit Alistair Francis
` (13 subsequent siblings)
23 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:33 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
Add the latest versionf of the socket-constants.h based on new Linux
---
.../sysv/linux/riscv/bits/socket-constants.h | 46 +++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 sysdeps/unix/sysv/linux/riscv/bits/socket-constants.h
diff --git a/sysdeps/unix/sysv/linux/riscv/bits/socket-constants.h b/sysdeps/unix/sysv/linux/riscv/bits/socket-constants.h
new file mode 100644
index 0000000000..7ecdfcbb61
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/bits/socket-constants.h
@@ -0,0 +1,46 @@
+/* Socket constants which vary among Linux architectures. Version for RV32.
+ Copyright (C) 2020 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
+ <https://www.gnu.org/licenses/>. */
+
+#ifndef _SYS_SOCKET_H
+# error "Never include <bits/socket-constants.h> directly; use <sys/socket.h> instead."
+#endif
+
+#define SOL_SOCKET 1
+#define SO_ACCEPTCONN 30
+#define SO_BROADCAST 6
+#define SO_DONTROUTE 5
+#define SO_ERROR 4
+#define SO_KEEPALIVE 9
+#define SO_LINGER 13
+#define SO_OOBINLINE 10
+#define SO_RCVBUF 8
+#define SO_RCVLOWAT 18
+#if __riscv_xlen == 32
+# define SO_RCVTIMEO 66
+#else
+# define SO_RCVTIMEO 20
+#endif
+#define SO_REUSEADDR 2
+#define SO_SNDBUF 7
+#define SO_SNDLOWAT 19
+#if __riscv_xlen == 32
+# define SO_SNDTIMEO 67
+#else
+# define SO_SNDTIMEO 21
+#endif
+#define SO_TYPE 3
--
2.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* [RFC v6 11/23] RISC-V: Support dynamic loader for the 32-bit
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (9 preceding siblings ...)
2020-01-12 10:33 ` [RFC v6 10/23] RISC-V: Add socket-constants.h for RV32 Alistair Francis
@ 2020-01-12 10:34 ` Alistair Francis
2020-01-12 10:34 ` [RFC v6 12/23] RISC-V: Add path of library directories " Alistair Francis
` (12 subsequent siblings)
23 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:34 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
From: Zong Li <zongbox@gmail.com>
Add the LD_SO_ABI definition for RISC-V 32-bit.
---
sysdeps/unix/sysv/linux/riscv/ldconfig.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sysdeps/unix/sysv/linux/riscv/ldconfig.h b/sysdeps/unix/sysv/linux/riscv/ldconfig.h
index 3d7065b293..35badb7cf0 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.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* [RFC v6 12/23] RISC-V: Add path of library directories for the 32-bit
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (10 preceding siblings ...)
2020-01-12 10:34 ` [RFC v6 11/23] RISC-V: Support dynamic loader for the 32-bit Alistair Francis
@ 2020-01-12 10:34 ` Alistair Francis
2020-01-12 10:34 ` [RFC v6 13/23] RISC-V: Add arch-syscall.h for RV32 Alistair Francis
` (11 subsequent siblings)
23 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:34 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
From: Zong Li <zongbox@gmail.com>
For the recommand of 64 bit version, we add the libraries path of 32 bit
in this patch.
The status of RV32 binaries under RV64 kernels is that the ISA
optionally supports having different XLEN for user and supervisor modes,
but AFAIK there's no silicon that implements this feature, and the Linux
kernel doesn't support it yet.
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.
---
sysdeps/unix/sysv/linux/riscv/dl-cache.h | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/sysdeps/unix/sysv/linux/riscv/dl-cache.h b/sysdeps/unix/sysv/linux/riscv/dl-cache.h
index c297dfe84f..60fc172edb 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.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* [RFC v6 13/23] RISC-V: Add arch-syscall.h for RV32
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (11 preceding siblings ...)
2020-01-12 10:34 ` [RFC v6 12/23] RISC-V: Add path of library directories " Alistair Francis
@ 2020-01-12 10:34 ` Alistair Francis
2020-01-12 10:34 ` [RFC v6 14/23] RISC-V: The ABI implementation for the 32-bit Alistair Francis
` (10 subsequent siblings)
23 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:34 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
---
.../unix/sysv/linux/riscv/rv32/arch-syscall.h | 281 ++++++++++++++++++
1 file changed, 281 insertions(+)
create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/arch-syscall.h
diff --git a/sysdeps/unix/sysv/linux/riscv/rv32/arch-syscall.h b/sysdeps/unix/sysv/linux/riscv/rv32/arch-syscall.h
new file mode 100644
index 0000000000..4d705162eb
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/rv32/arch-syscall.h
@@ -0,0 +1,281 @@
+/* AUTOGENERATED by update-syscall-lists.py. */
+#define __NR_accept 202
+#define __NR_accept4 242
+#define __NR_acct 89
+#define __NR_add_key 217
+#define __NR_bind 200
+#define __NR_bpf 280
+#define __NR_brk 214
+#define __NR_capget 90
+#define __NR_capset 91
+#define __NR_chdir 49
+#define __NR_chroot 51
+#define __NR_clock_adjtime64 405
+#define __NR_clock_getres_time64 406
+#define __NR_clock_gettime64 403
+#define __NR_clock_nanosleep_time64 407
+#define __NR_clock_settime64 404
+#define __NR_clone 220
+#define __NR_close 57
+#define __NR_connect 203
+#define __NR_copy_file_range 285
+#define __NR_delete_module 106
+#define __NR_dup 23
+#define __NR_dup3 24
+#define __NR_epoll_create1 20
+#define __NR_epoll_ctl 21
+#define __NR_epoll_pwait 22
+#define __NR_eventfd2 19
+#define __NR_execve 221
+#define __NR_execveat 281
+#define __NR_exit 93
+#define __NR_exit_group 94
+#define __NR_faccessat 48
+#define __NR_fadvise64_64 223
+#define __NR_fallocate 47
+#define __NR_fanotify_init 262
+#define __NR_fanotify_mark 263
+#define __NR_fchdir 50
+#define __NR_fchmod 52
+#define __NR_fchmodat 53
+#define __NR_fchown 55
+#define __NR_fchownat 54
+#define __NR_fcntl64 25
+#define __NR_fdatasync 83
+#define __NR_fgetxattr 10
+#define __NR_finit_module 273
+#define __NR_flistxattr 13
+#define __NR_flock 32
+#define __NR_fremovexattr 16
+#define __NR_fsconfig 431
+#define __NR_fsetxattr 7
+#define __NR_fsmount 432
+#define __NR_fsopen 430
+#define __NR_fspick 433
+#define __NR_fstatfs64 44
+#define __NR_fsync 82
+#define __NR_ftruncate64 46
+#define __NR_futex_time64 422
+#define __NR_get_mempolicy 236
+#define __NR_get_robust_list 100
+#define __NR_getcpu 168
+#define __NR_getcwd 17
+#define __NR_getdents64 61
+#define __NR_getegid 177
+#define __NR_geteuid 175
+#define __NR_getgid 176
+#define __NR_getgroups 158
+#define __NR_getitimer 102
+#define __NR_getpeername 205
+#define __NR_getpgid 155
+#define __NR_getpid 172
+#define __NR_getppid 173
+#define __NR_getpriority 141
+#define __NR_getrandom 278
+#define __NR_getresgid 150
+#define __NR_getresuid 148
+#define __NR_getrusage 165
+#define __NR_getsid 156
+#define __NR_getsockname 204
+#define __NR_getsockopt 209
+#define __NR_gettid 178
+#define __NR_getuid 174
+#define __NR_getxattr 8
+#define __NR_init_module 105
+#define __NR_inotify_add_watch 27
+#define __NR_inotify_init1 26
+#define __NR_inotify_rm_watch 28
+#define __NR_io_cancel 3
+#define __NR_io_destroy 1
+#define __NR_io_pgetevents_time64 416
+#define __NR_io_setup 0
+#define __NR_io_submit 2
+#define __NR_io_uring_enter 426
+#define __NR_io_uring_register 427
+#define __NR_io_uring_setup 425
+#define __NR_ioctl 29
+#define __NR_ioprio_get 31
+#define __NR_ioprio_set 30
+#define __NR_kcmp 272
+#define __NR_kexec_file_load 294
+#define __NR_kexec_load 104
+#define __NR_keyctl 219
+#define __NR_kill 129
+#define __NR_lgetxattr 9
+#define __NR_linkat 37
+#define __NR_listen 201
+#define __NR_listxattr 11
+#define __NR_llistxattr 12
+#define __NR_llseek 62
+#define __NR_lookup_dcookie 18
+#define __NR_lremovexattr 15
+#define __NR_lsetxattr 6
+#define __NR_madvise 233
+#define __NR_mbind 235
+#define __NR_membarrier 283
+#define __NR_memfd_create 279
+#define __NR_migrate_pages 238
+#define __NR_mincore 232
+#define __NR_mkdirat 34
+#define __NR_mknodat 33
+#define __NR_mlock 228
+#define __NR_mlock2 284
+#define __NR_mlockall 230
+#define __NR_mmap2 222
+#define __NR_mount 40
+#define __NR_move_mount 429
+#define __NR_move_pages 239
+#define __NR_mprotect 226
+#define __NR_mq_getsetattr 185
+#define __NR_mq_notify 184
+#define __NR_mq_open 180
+#define __NR_mq_timedreceive_time64 419
+#define __NR_mq_timedsend_time64 418
+#define __NR_mq_unlink 181
+#define __NR_mremap 216
+#define __NR_msgctl 187
+#define __NR_msgget 186
+#define __NR_msgrcv 188
+#define __NR_msgsnd 189
+#define __NR_msync 227
+#define __NR_munlock 229
+#define __NR_munlockall 231
+#define __NR_munmap 215
+#define __NR_name_to_handle_at 264
+#define __NR_nfsservctl 42
+#define __NR_open_by_handle_at 265
+#define __NR_open_tree 428
+#define __NR_openat 56
+#define __NR_perf_event_open 241
+#define __NR_personality 92
+#define __NR_pidfd_open 434
+#define __NR_pidfd_send_signal 424
+#define __NR_pipe2 59
+#define __NR_pivot_root 41
+#define __NR_pkey_alloc 289
+#define __NR_pkey_free 290
+#define __NR_pkey_mprotect 288
+#define __NR_ppoll_time64 414
+#define __NR_prctl 167
+#define __NR_pread64 67
+#define __NR_preadv 69
+#define __NR_preadv2 286
+#define __NR_prlimit64 261
+#define __NR_process_vm_readv 270
+#define __NR_process_vm_writev 271
+#define __NR_pselect6_time64 413
+#define __NR_ptrace 117
+#define __NR_pwrite64 68
+#define __NR_pwritev 70
+#define __NR_pwritev2 287
+#define __NR_quotactl 60
+#define __NR_read 63
+#define __NR_readahead 213
+#define __NR_readlinkat 78
+#define __NR_readv 65
+#define __NR_reboot 142
+#define __NR_recvfrom 207
+#define __NR_recvmmsg_time64 417
+#define __NR_recvmsg 212
+#define __NR_remap_file_pages 234
+#define __NR_removexattr 14
+#define __NR_renameat2 276
+#define __NR_request_key 218
+#define __NR_restart_syscall 128
+#define __NR_riscv_flush_icache 259
+#define __NR_rseq 293
+#define __NR_rt_sigaction 134
+#define __NR_rt_sigpending 136
+#define __NR_rt_sigprocmask 135
+#define __NR_rt_sigqueueinfo 138
+#define __NR_rt_sigreturn 139
+#define __NR_rt_sigsuspend 133
+#define __NR_rt_sigtimedwait_time64 421
+#define __NR_rt_tgsigqueueinfo 240
+#define __NR_sched_get_priority_max 125
+#define __NR_sched_get_priority_min 126
+#define __NR_sched_getaffinity 123
+#define __NR_sched_getattr 275
+#define __NR_sched_getparam 121
+#define __NR_sched_getscheduler 120
+#define __NR_sched_rr_get_interval_time64 423
+#define __NR_sched_setaffinity 122
+#define __NR_sched_setattr 274
+#define __NR_sched_setparam 118
+#define __NR_sched_setscheduler 119
+#define __NR_sched_yield 124
+#define __NR_seccomp 277
+#define __NR_semctl 191
+#define __NR_semget 190
+#define __NR_semop 193
+#define __NR_semtimedop_time64 420
+#define __NR_sendfile64 71
+#define __NR_sendmmsg 269
+#define __NR_sendmsg 211
+#define __NR_sendto 206
+#define __NR_set_mempolicy 237
+#define __NR_set_robust_list 99
+#define __NR_set_tid_address 96
+#define __NR_setdomainname 162
+#define __NR_setfsgid 152
+#define __NR_setfsuid 151
+#define __NR_setgid 144
+#define __NR_setgroups 159
+#define __NR_sethostname 161
+#define __NR_setitimer 103
+#define __NR_setns 268
+#define __NR_setpgid 154
+#define __NR_setpriority 140
+#define __NR_setregid 143
+#define __NR_setresgid 149
+#define __NR_setresuid 147
+#define __NR_setreuid 145
+#define __NR_setsid 157
+#define __NR_setsockopt 208
+#define __NR_setuid 146
+#define __NR_setxattr 5
+#define __NR_shmat 196
+#define __NR_shmctl 195
+#define __NR_shmdt 197
+#define __NR_shmget 194
+#define __NR_shutdown 210
+#define __NR_sigaltstack 132
+#define __NR_signalfd4 74
+#define __NR_socket 198
+#define __NR_socketpair 199
+#define __NR_splice 76
+#define __NR_statfs64 43
+#define __NR_statx 291
+#define __NR_swapoff 225
+#define __NR_swapon 224
+#define __NR_symlinkat 36
+#define __NR_sync 81
+#define __NR_sync_file_range 84
+#define __NR_syncfs 267
+#define __NR_sysinfo 179
+#define __NR_syslog 116
+#define __NR_tee 77
+#define __NR_tgkill 131
+#define __NR_timer_create 107
+#define __NR_timer_delete 111
+#define __NR_timer_getoverrun 109
+#define __NR_timer_gettime64 408
+#define __NR_timer_settime64 409
+#define __NR_timerfd_create 85
+#define __NR_timerfd_gettime64 410
+#define __NR_timerfd_settime64 411
+#define __NR_times 153
+#define __NR_tkill 130
+#define __NR_truncate64 45
+#define __NR_umask 166
+#define __NR_umount2 39
+#define __NR_uname 160
+#define __NR_unlinkat 35
+#define __NR_unshare 97
+#define __NR_userfaultfd 282
+#define __NR_utimensat_time64 412
+#define __NR_vhangup 58
+#define __NR_vmsplice 75
+#define __NR_waitid 95
+#define __NR_write 64
+#define __NR_writev 66
--
2.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* [RFC v6 14/23] RISC-V: The ABI implementation for the 32-bit
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (12 preceding siblings ...)
2020-01-12 10:34 ` [RFC v6 13/23] RISC-V: Add arch-syscall.h for RV32 Alistair Francis
@ 2020-01-12 10:34 ` Alistair Francis
2020-01-12 10:34 ` [RFC v6 15/23] RISC-V: Hard float support for 32-bit Alistair Francis
` (9 subsequent siblings)
23 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:34 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
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.
---
sysdeps/riscv/bits/wordsize.h | 4 +-
sysdeps/riscv/nptl/bits/pthreadtypes-arch.h | 10 +++-
sysdeps/riscv/nptl/bits/struct_rwlock.h | 27 +++++++++-
sysdeps/riscv/sfp-machine.h | 27 +++++++++-
sysdeps/riscv/sys/asm.h | 5 +-
.../unix/sysv/linux/riscv/jmp_buf-macros.h | 53 +++++++++++++++++++
6 files changed, 121 insertions(+), 5 deletions(-)
create mode 100644 sysdeps/unix/sysv/linux/riscv/jmp_buf-macros.h
diff --git a/sysdeps/riscv/bits/wordsize.h b/sysdeps/riscv/bits/wordsize.h
index faccc71828..ee430d9036 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 c3c72d6c10..363034c38a 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 __LOCK_ALIGNMENT
diff --git a/sysdeps/riscv/nptl/bits/struct_rwlock.h b/sysdeps/riscv/nptl/bits/struct_rwlock.h
index acfaa75e1b..b478da0132 100644
--- a/sysdeps/riscv/nptl/bits/struct_rwlock.h
+++ b/sysdeps/riscv/nptl/bits/struct_rwlock.h
@@ -32,14 +32,39 @@ 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_INITIALIZER(__flags) \
+#if __riscv_xlen == 64
+# define __PTHREAD_RWLOCK_INITIALIZER(__flags) \
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, __flags
+#else
+# if __BYTE_ORDER == __BIG_ENDIAN
+# define __PTHREAD_RWLOCK_INITIALIZER(__flags) \
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, __flags, 0
+# else
+# define __PTHREAD_RWLOCK_INITIALIZER(__flags) \
+ 0, 0, 0, 0, 0, 0, __flags, 0, 0, 0, 0
+# endif
+#endif
#endif
diff --git a/sysdeps/riscv/sfp-machine.h b/sysdeps/riscv/sfp-machine.h
index 08a84fd701..aef8c61a67 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 bd2de17e17..e314133ce4 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/jmp_buf-macros.h b/sysdeps/unix/sysv/linux/riscv/jmp_buf-macros.h
new file mode 100644
index 0000000000..7e48f24345
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/jmp_buf-macros.h
@@ -0,0 +1,53 @@
+/* jump buffer constants for RISC-V
+ Copyright (C) 2017-2020 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.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* [RFC v6 15/23] RISC-V: Hard float support for 32-bit
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (13 preceding siblings ...)
2020-01-12 10:34 ` [RFC v6 14/23] RISC-V: The ABI implementation for the 32-bit Alistair Francis
@ 2020-01-12 10:34 ` Alistair Francis
2020-01-12 10:34 ` [RFC v6 16/23] RISC-V: Add ABI lists Alistair Francis
` (8 subsequent siblings)
23 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:34 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
From: Zong Li <zongbox@gmail.com>
This patch contains hardware floating-point support for the RV32IF and
RV32IFD
---
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 ++++++++++++++++++++++++++++++
4 files changed, 124 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/sysdeps/riscv/rv32/rvd/s_lrint.c b/sysdeps/riscv/rv32/rvd/s_lrint.c
new file mode 100644
index 0000000000..df406aacb6
--- /dev/null
+++ b/sysdeps/riscv/rv32/rvd/s_lrint.c
@@ -0,0 +1,31 @@
+/* lrint(). RISC-V version.
+ Copyright (C) 2017-2020 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..72aa2b179d
--- /dev/null
+++ b/sysdeps/riscv/rv32/rvd/s_lround.c
@@ -0,0 +1,31 @@
+/* lround(). RISC-V version.
+ Copyright (C) 2017-2020 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..9ff5d63d1c
--- /dev/null
+++ b/sysdeps/riscv/rv32/rvf/s_lroundf.c
@@ -0,0 +1,31 @@
+/* lroundf(). RISC-V version.
+ Copyright (C) 2017-2020 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.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* [RFC v6 16/23] RISC-V: Add ABI lists
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (14 preceding siblings ...)
2020-01-12 10:34 ` [RFC v6 15/23] RISC-V: Hard float support for 32-bit Alistair Francis
@ 2020-01-12 10:34 ` Alistair Francis
2020-01-12 10:34 ` [RFC v6 17/23] RISC-V: Add the RV32 libm-test-ulps Alistair Francis
` (7 subsequent siblings)
23 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:34 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
Use the check-api and update-abi to generate the abilist for rv32.
---
sysdeps/unix/sysv/linux/riscv/c++-types.data | 67 +
sysdeps/unix/sysv/linux/riscv/ld.abilist | 9 +
.../sysv/linux/riscv/libBrokenLocale.abilist | 1 +
sysdeps/unix/sysv/linux/riscv/libanl.abilist | 4 +
sysdeps/unix/sysv/linux/riscv/libc.abilist | 2095 +++++++++++++++++
.../unix/sysv/linux/riscv/libcrypt.abilist | 2 +
sysdeps/unix/sysv/linux/riscv/libdl.abilist | 9 +
sysdeps/unix/sysv/linux/riscv/libm.abilist | 940 ++++++++
.../unix/sysv/linux/riscv/libpthread.abilist | 227 ++
.../unix/sysv/linux/riscv/libresolv.abilist | 79 +
sysdeps/unix/sysv/linux/riscv/librt.abilist | 35 +
.../sysv/linux/riscv/libthread_db.abilist | 40 +
sysdeps/unix/sysv/linux/riscv/libutil.abilist | 6 +
13 files changed, 3514 insertions(+)
create mode 100644 sysdeps/unix/sysv/linux/riscv/c++-types.data
create mode 100644 sysdeps/unix/sysv/linux/riscv/ld.abilist
create mode 100644 sysdeps/unix/sysv/linux/riscv/libBrokenLocale.abilist
create mode 100644 sysdeps/unix/sysv/linux/riscv/libanl.abilist
create mode 100644 sysdeps/unix/sysv/linux/riscv/libc.abilist
create mode 100644 sysdeps/unix/sysv/linux/riscv/libcrypt.abilist
create mode 100644 sysdeps/unix/sysv/linux/riscv/libdl.abilist
create mode 100644 sysdeps/unix/sysv/linux/riscv/libm.abilist
create mode 100644 sysdeps/unix/sysv/linux/riscv/libpthread.abilist
create mode 100644 sysdeps/unix/sysv/linux/riscv/libresolv.abilist
create mode 100644 sysdeps/unix/sysv/linux/riscv/librt.abilist
create mode 100644 sysdeps/unix/sysv/linux/riscv/libthread_db.abilist
create mode 100644 sysdeps/unix/sysv/linux/riscv/libutil.abilist
diff --git a/sysdeps/unix/sysv/linux/riscv/c++-types.data b/sysdeps/unix/sysv/linux/riscv/c++-types.data
new file mode 100644
index 0000000000..0fb0143ae7
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/c++-types.data
@@ -0,0 +1,67 @@
+blkcnt64_t:x
+blkcnt_t:x
+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:y
+fsfilcnt64_t:y
+fsfilcnt_t:y
+fsid_t:8__fsid_t
+gid_t:j
+id_t:j
+ino64_t:y
+ino_t:y
+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:x
+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:y
+sigset_t:10__sigset_t
+size_t:j
+socklen_t:j
+ssize_t:i
+suseconds_t:x
+time_t:x
+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/ld.abilist b/sysdeps/unix/sysv/linux/riscv/ld.abilist
new file mode 100644
index 0000000000..1515b0977c
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/ld.abilist
@@ -0,0 +1,9 @@
+GLIBC_2.31 __libc_stack_end D 0x4
+GLIBC_2.31 __stack_chk_guard D 0x4
+GLIBC_2.31 __tls_get_addr F
+GLIBC_2.31 _dl_mcount F
+GLIBC_2.31 _r_debug D 0x14
+GLIBC_2.31 calloc F
+GLIBC_2.31 free F
+GLIBC_2.31 malloc F
+GLIBC_2.31 realloc F
diff --git a/sysdeps/unix/sysv/linux/riscv/libBrokenLocale.abilist b/sysdeps/unix/sysv/linux/riscv/libBrokenLocale.abilist
new file mode 100644
index 0000000000..55b5eb8193
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/libBrokenLocale.abilist
@@ -0,0 +1 @@
+GLIBC_2.31 __ctype_get_mb_cur_max F
diff --git a/sysdeps/unix/sysv/linux/riscv/libanl.abilist b/sysdeps/unix/sysv/linux/riscv/libanl.abilist
new file mode 100644
index 0000000000..2b096eb1f0
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/libanl.abilist
@@ -0,0 +1,4 @@
+GLIBC_2.31 gai_cancel F
+GLIBC_2.31 gai_error F
+GLIBC_2.31 gai_suspend F
+GLIBC_2.31 getaddrinfo_a F
diff --git a/sysdeps/unix/sysv/linux/riscv/libc.abilist b/sysdeps/unix/sysv/linux/riscv/libc.abilist
new file mode 100644
index 0000000000..f46934704e
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/libc.abilist
@@ -0,0 +1,2095 @@
+GLIBC_2.31 _Exit F
+GLIBC_2.31 _IO_2_1_stderr_ D 0xa0
+GLIBC_2.31 _IO_2_1_stdin_ D 0xa0
+GLIBC_2.31 _IO_2_1_stdout_ D 0xa0
+GLIBC_2.31 _IO_adjust_column F
+GLIBC_2.31 _IO_adjust_wcolumn F
+GLIBC_2.31 _IO_default_doallocate F
+GLIBC_2.31 _IO_default_finish F
+GLIBC_2.31 _IO_default_pbackfail F
+GLIBC_2.31 _IO_default_uflow F
+GLIBC_2.31 _IO_default_xsgetn F
+GLIBC_2.31 _IO_default_xsputn F
+GLIBC_2.31 _IO_do_write F
+GLIBC_2.31 _IO_doallocbuf F
+GLIBC_2.31 _IO_fclose F
+GLIBC_2.31 _IO_fdopen F
+GLIBC_2.31 _IO_feof F
+GLIBC_2.31 _IO_ferror F
+GLIBC_2.31 _IO_fflush F
+GLIBC_2.31 _IO_fgetpos F
+GLIBC_2.31 _IO_fgetpos64 F
+GLIBC_2.31 _IO_fgets F
+GLIBC_2.31 _IO_file_attach F
+GLIBC_2.31 _IO_file_close F
+GLIBC_2.31 _IO_file_close_it F
+GLIBC_2.31 _IO_file_doallocate F
+GLIBC_2.31 _IO_file_finish F
+GLIBC_2.31 _IO_file_fopen F
+GLIBC_2.31 _IO_file_init F
+GLIBC_2.31 _IO_file_jumps D 0x54
+GLIBC_2.31 _IO_file_open F
+GLIBC_2.31 _IO_file_overflow F
+GLIBC_2.31 _IO_file_read F
+GLIBC_2.31 _IO_file_seek F
+GLIBC_2.31 _IO_file_seekoff F
+GLIBC_2.31 _IO_file_setbuf F
+GLIBC_2.31 _IO_file_stat F
+GLIBC_2.31 _IO_file_sync F
+GLIBC_2.31 _IO_file_underflow F
+GLIBC_2.31 _IO_file_write F
+GLIBC_2.31 _IO_file_xsputn F
+GLIBC_2.31 _IO_flockfile F
+GLIBC_2.31 _IO_flush_all F
+GLIBC_2.31 _IO_flush_all_linebuffered F
+GLIBC_2.31 _IO_fopen F
+GLIBC_2.31 _IO_fprintf F
+GLIBC_2.31 _IO_fputs F
+GLIBC_2.31 _IO_fread F
+GLIBC_2.31 _IO_free_backup_area F
+GLIBC_2.31 _IO_free_wbackup_area F
+GLIBC_2.31 _IO_fsetpos F
+GLIBC_2.31 _IO_fsetpos64 F
+GLIBC_2.31 _IO_ftell F
+GLIBC_2.31 _IO_ftrylockfile F
+GLIBC_2.31 _IO_funlockfile F
+GLIBC_2.31 _IO_fwrite F
+GLIBC_2.31 _IO_getc F
+GLIBC_2.31 _IO_getline F
+GLIBC_2.31 _IO_getline_info F
+GLIBC_2.31 _IO_gets F
+GLIBC_2.31 _IO_init F
+GLIBC_2.31 _IO_init_marker F
+GLIBC_2.31 _IO_init_wmarker F
+GLIBC_2.31 _IO_iter_begin F
+GLIBC_2.31 _IO_iter_end F
+GLIBC_2.31 _IO_iter_file F
+GLIBC_2.31 _IO_iter_next F
+GLIBC_2.31 _IO_least_wmarker F
+GLIBC_2.31 _IO_link_in F
+GLIBC_2.31 _IO_list_all D 0x4
+GLIBC_2.31 _IO_list_lock F
+GLIBC_2.31 _IO_list_resetlock F
+GLIBC_2.31 _IO_list_unlock F
+GLIBC_2.31 _IO_marker_delta F
+GLIBC_2.31 _IO_marker_difference F
+GLIBC_2.31 _IO_padn F
+GLIBC_2.31 _IO_peekc_locked F
+GLIBC_2.31 _IO_popen F
+GLIBC_2.31 _IO_printf F
+GLIBC_2.31 _IO_proc_close F
+GLIBC_2.31 _IO_proc_open F
+GLIBC_2.31 _IO_putc F
+GLIBC_2.31 _IO_puts F
+GLIBC_2.31 _IO_remove_marker F
+GLIBC_2.31 _IO_seekmark F
+GLIBC_2.31 _IO_seekoff F
+GLIBC_2.31 _IO_seekpos F
+GLIBC_2.31 _IO_seekwmark F
+GLIBC_2.31 _IO_setb F
+GLIBC_2.31 _IO_setbuffer F
+GLIBC_2.31 _IO_setvbuf F
+GLIBC_2.31 _IO_sgetn F
+GLIBC_2.31 _IO_sprintf F
+GLIBC_2.31 _IO_sputbackc F
+GLIBC_2.31 _IO_sputbackwc F
+GLIBC_2.31 _IO_sscanf F
+GLIBC_2.31 _IO_str_init_readonly F
+GLIBC_2.31 _IO_str_init_static F
+GLIBC_2.31 _IO_str_overflow F
+GLIBC_2.31 _IO_str_pbackfail F
+GLIBC_2.31 _IO_str_seekoff F
+GLIBC_2.31 _IO_str_underflow F
+GLIBC_2.31 _IO_sungetc F
+GLIBC_2.31 _IO_sungetwc F
+GLIBC_2.31 _IO_switch_to_get_mode F
+GLIBC_2.31 _IO_switch_to_main_wget_area F
+GLIBC_2.31 _IO_switch_to_wbackup_area F
+GLIBC_2.31 _IO_switch_to_wget_mode F
+GLIBC_2.31 _IO_un_link F
+GLIBC_2.31 _IO_ungetc F
+GLIBC_2.31 _IO_unsave_markers F
+GLIBC_2.31 _IO_unsave_wmarkers F
+GLIBC_2.31 _IO_vfprintf F
+GLIBC_2.31 _IO_vsprintf F
+GLIBC_2.31 _IO_wdefault_doallocate F
+GLIBC_2.31 _IO_wdefault_finish F
+GLIBC_2.31 _IO_wdefault_pbackfail F
+GLIBC_2.31 _IO_wdefault_uflow F
+GLIBC_2.31 _IO_wdefault_xsgetn F
+GLIBC_2.31 _IO_wdefault_xsputn F
+GLIBC_2.31 _IO_wdo_write F
+GLIBC_2.31 _IO_wdoallocbuf F
+GLIBC_2.31 _IO_wfile_jumps D 0x54
+GLIBC_2.31 _IO_wfile_overflow F
+GLIBC_2.31 _IO_wfile_seekoff F
+GLIBC_2.31 _IO_wfile_sync F
+GLIBC_2.31 _IO_wfile_underflow F
+GLIBC_2.31 _IO_wfile_xsputn F
+GLIBC_2.31 _IO_wmarker_delta F
+GLIBC_2.31 _IO_wsetb F
+GLIBC_2.31 ___brk_addr D 0x4
+GLIBC_2.31 __adjtimex F
+GLIBC_2.31 __after_morecore_hook D 0x4
+GLIBC_2.31 __argz_count F
+GLIBC_2.31 __argz_next F
+GLIBC_2.31 __argz_stringify F
+GLIBC_2.31 __asprintf F
+GLIBC_2.31 __asprintf_chk F
+GLIBC_2.31 __assert F
+GLIBC_2.31 __assert_fail F
+GLIBC_2.31 __assert_perror_fail F
+GLIBC_2.31 __backtrace F
+GLIBC_2.31 __backtrace_symbols F
+GLIBC_2.31 __backtrace_symbols_fd F
+GLIBC_2.31 __bsd_getpgrp F
+GLIBC_2.31 __bzero F
+GLIBC_2.31 __check_rhosts_file D 0x4
+GLIBC_2.31 __chk_fail F
+GLIBC_2.31 __clone F
+GLIBC_2.31 __close F
+GLIBC_2.31 __cmsg_nxthdr F
+GLIBC_2.31 __confstr_chk F
+GLIBC_2.31 __connect F
+GLIBC_2.31 __ctype_b_loc F
+GLIBC_2.31 __ctype_get_mb_cur_max F
+GLIBC_2.31 __ctype_tolower_loc F
+GLIBC_2.31 __ctype_toupper_loc F
+GLIBC_2.31 __curbrk D 0x4
+GLIBC_2.31 __cxa_at_quick_exit F
+GLIBC_2.31 __cxa_atexit F
+GLIBC_2.31 __cxa_finalize F
+GLIBC_2.31 __cxa_thread_atexit_impl F
+GLIBC_2.31 __cyg_profile_func_enter F
+GLIBC_2.31 __cyg_profile_func_exit F
+GLIBC_2.31 __daylight D 0x4
+GLIBC_2.31 __dcgettext F
+GLIBC_2.31 __default_morecore F
+GLIBC_2.31 __dgettext F
+GLIBC_2.31 __dprintf_chk F
+GLIBC_2.31 __dup2 F
+GLIBC_2.31 __duplocale F
+GLIBC_2.31 __endmntent F
+GLIBC_2.31 __environ D 0x4
+GLIBC_2.31 __errno_location F
+GLIBC_2.31 __explicit_bzero_chk F
+GLIBC_2.31 __fbufsize F
+GLIBC_2.31 __fcntl F
+GLIBC_2.31 __fdelt_chk F
+GLIBC_2.31 __fdelt_warn F
+GLIBC_2.31 __ffs F
+GLIBC_2.31 __fgets_chk F
+GLIBC_2.31 __fgets_unlocked_chk F
+GLIBC_2.31 __fgetws_chk F
+GLIBC_2.31 __fgetws_unlocked_chk F
+GLIBC_2.31 __finite F
+GLIBC_2.31 __finitef F
+GLIBC_2.31 __finitel F
+GLIBC_2.31 __flbf F
+GLIBC_2.31 __fork F
+GLIBC_2.31 __fpending F
+GLIBC_2.31 __fprintf_chk F
+GLIBC_2.31 __fpu_control D 0x4
+GLIBC_2.31 __fpurge F
+GLIBC_2.31 __fread_chk F
+GLIBC_2.31 __fread_unlocked_chk F
+GLIBC_2.31 __freadable F
+GLIBC_2.31 __freading F
+GLIBC_2.31 __free_hook D 0x4
+GLIBC_2.31 __freelocale F
+GLIBC_2.31 __fsetlocking F
+GLIBC_2.31 __fwprintf_chk F
+GLIBC_2.31 __fwritable F
+GLIBC_2.31 __fwriting F
+GLIBC_2.31 __fxstat F
+GLIBC_2.31 __fxstat64 F
+GLIBC_2.31 __fxstatat F
+GLIBC_2.31 __fxstatat64 F
+GLIBC_2.31 __getauxval F
+GLIBC_2.31 __getcwd_chk F
+GLIBC_2.31 __getdelim F
+GLIBC_2.31 __getdomainname_chk F
+GLIBC_2.31 __getgroups_chk F
+GLIBC_2.31 __gethostname_chk F
+GLIBC_2.31 __getlogin_r_chk F
+GLIBC_2.31 __getmntent_r F
+GLIBC_2.31 __getpagesize F
+GLIBC_2.31 __getpgid F
+GLIBC_2.31 __getpid F
+GLIBC_2.31 __gets_chk F
+GLIBC_2.31 __gettimeofday F
+GLIBC_2.31 __getwd_chk F
+GLIBC_2.31 __gmtime_r F
+GLIBC_2.31 __h_errno_location F
+GLIBC_2.31 __isalnum_l F
+GLIBC_2.31 __isalpha_l F
+GLIBC_2.31 __isascii_l F
+GLIBC_2.31 __isblank_l F
+GLIBC_2.31 __iscntrl_l F
+GLIBC_2.31 __isctype F
+GLIBC_2.31 __isdigit_l F
+GLIBC_2.31 __isgraph_l F
+GLIBC_2.31 __isinf F
+GLIBC_2.31 __isinff F
+GLIBC_2.31 __isinfl F
+GLIBC_2.31 __islower_l F
+GLIBC_2.31 __isnan F
+GLIBC_2.31 __isnanf F
+GLIBC_2.31 __isnanl F
+GLIBC_2.31 __isoc99_fscanf F
+GLIBC_2.31 __isoc99_fwscanf F
+GLIBC_2.31 __isoc99_scanf F
+GLIBC_2.31 __isoc99_sscanf F
+GLIBC_2.31 __isoc99_swscanf F
+GLIBC_2.31 __isoc99_vfscanf F
+GLIBC_2.31 __isoc99_vfwscanf F
+GLIBC_2.31 __isoc99_vscanf F
+GLIBC_2.31 __isoc99_vsscanf F
+GLIBC_2.31 __isoc99_vswscanf F
+GLIBC_2.31 __isoc99_vwscanf F
+GLIBC_2.31 __isoc99_wscanf F
+GLIBC_2.31 __isprint_l F
+GLIBC_2.31 __ispunct_l F
+GLIBC_2.31 __isspace_l F
+GLIBC_2.31 __isupper_l F
+GLIBC_2.31 __iswalnum_l F
+GLIBC_2.31 __iswalpha_l F
+GLIBC_2.31 __iswblank_l F
+GLIBC_2.31 __iswcntrl_l F
+GLIBC_2.31 __iswctype F
+GLIBC_2.31 __iswctype_l F
+GLIBC_2.31 __iswdigit_l F
+GLIBC_2.31 __iswgraph_l F
+GLIBC_2.31 __iswlower_l F
+GLIBC_2.31 __iswprint_l F
+GLIBC_2.31 __iswpunct_l F
+GLIBC_2.31 __iswspace_l F
+GLIBC_2.31 __iswupper_l F
+GLIBC_2.31 __iswxdigit_l F
+GLIBC_2.31 __isxdigit_l F
+GLIBC_2.31 __ivaliduser F
+GLIBC_2.31 __key_decryptsession_pk_LOCAL D 0x4
+GLIBC_2.31 __key_encryptsession_pk_LOCAL D 0x4
+GLIBC_2.31 __key_gendes_LOCAL D 0x4
+GLIBC_2.31 __libc_allocate_rtsig F
+GLIBC_2.31 __libc_calloc F
+GLIBC_2.31 __libc_current_sigrtmax F
+GLIBC_2.31 __libc_current_sigrtmin F
+GLIBC_2.31 __libc_free F
+GLIBC_2.31 __libc_freeres F
+GLIBC_2.31 __libc_init_first F
+GLIBC_2.31 __libc_mallinfo F
+GLIBC_2.31 __libc_malloc F
+GLIBC_2.31 __libc_mallopt F
+GLIBC_2.31 __libc_memalign F
+GLIBC_2.31 __libc_pvalloc F
+GLIBC_2.31 __libc_realloc F
+GLIBC_2.31 __libc_sa_len F
+GLIBC_2.31 __libc_start_main F
+GLIBC_2.31 __libc_valloc F
+GLIBC_2.31 __longjmp_chk F
+GLIBC_2.31 __lseek F
+GLIBC_2.31 __lxstat F
+GLIBC_2.31 __lxstat64 F
+GLIBC_2.31 __malloc_hook D 0x4
+GLIBC_2.31 __mbrlen F
+GLIBC_2.31 __mbrtowc F
+GLIBC_2.31 __mbsnrtowcs_chk F
+GLIBC_2.31 __mbsrtowcs_chk F
+GLIBC_2.31 __mbstowcs_chk F
+GLIBC_2.31 __memalign_hook D 0x4
+GLIBC_2.31 __memcpy_chk F
+GLIBC_2.31 __memmove_chk F
+GLIBC_2.31 __mempcpy F
+GLIBC_2.31 __mempcpy_chk F
+GLIBC_2.31 __memset_chk F
+GLIBC_2.31 __monstartup F
+GLIBC_2.31 __morecore D 0x4
+GLIBC_2.31 __nanosleep F
+GLIBC_2.31 __newlocale F
+GLIBC_2.31 __nl_langinfo_l F
+GLIBC_2.31 __nss_configure_lookup F
+GLIBC_2.31 __nss_hostname_digits_dots F
+GLIBC_2.31 __obstack_printf_chk F
+GLIBC_2.31 __obstack_vprintf_chk F
+GLIBC_2.31 __open F
+GLIBC_2.31 __open64 F
+GLIBC_2.31 __open64_2 F
+GLIBC_2.31 __open_2 F
+GLIBC_2.31 __openat64_2 F
+GLIBC_2.31 __openat_2 F
+GLIBC_2.31 __overflow F
+GLIBC_2.31 __pipe F
+GLIBC_2.31 __poll F
+GLIBC_2.31 __poll_chk F
+GLIBC_2.31 __posix_getopt F
+GLIBC_2.31 __ppoll_chk F
+GLIBC_2.31 __pread64 F
+GLIBC_2.31 __pread64_chk F
+GLIBC_2.31 __pread_chk F
+GLIBC_2.31 __printf_chk F
+GLIBC_2.31 __printf_fp F
+GLIBC_2.31 __profile_frequency F
+GLIBC_2.31 __progname D 0x4
+GLIBC_2.31 __progname_full D 0x4
+GLIBC_2.31 __ptsname_r_chk F
+GLIBC_2.31 __pwrite64 F
+GLIBC_2.31 __rawmemchr F
+GLIBC_2.31 __rcmd_errstr D 0x4
+GLIBC_2.31 __read F
+GLIBC_2.31 __read_chk F
+GLIBC_2.31 __readlink_chk F
+GLIBC_2.31 __readlinkat_chk F
+GLIBC_2.31 __realloc_hook D 0x4
+GLIBC_2.31 __realpath_chk F
+GLIBC_2.31 __recv_chk F
+GLIBC_2.31 __recvfrom_chk F
+GLIBC_2.31 __register_atfork F
+GLIBC_2.31 __res_init F
+GLIBC_2.31 __res_nclose F
+GLIBC_2.31 __res_ninit F
+GLIBC_2.31 __res_randomid F
+GLIBC_2.31 __res_state F
+GLIBC_2.31 __riscv_flush_icache F
+GLIBC_2.31 __rpc_thread_createerr F
+GLIBC_2.31 __rpc_thread_svc_fdset F
+GLIBC_2.31 __rpc_thread_svc_max_pollfd F
+GLIBC_2.31 __rpc_thread_svc_pollfd F
+GLIBC_2.31 __sbrk F
+GLIBC_2.31 __sched_cpualloc F
+GLIBC_2.31 __sched_cpucount F
+GLIBC_2.31 __sched_cpufree F
+GLIBC_2.31 __sched_get_priority_max F
+GLIBC_2.31 __sched_get_priority_min F
+GLIBC_2.31 __sched_getparam F
+GLIBC_2.31 __sched_getscheduler F
+GLIBC_2.31 __sched_setscheduler F
+GLIBC_2.31 __sched_yield F
+GLIBC_2.31 __select F
+GLIBC_2.31 __send F
+GLIBC_2.31 __setmntent F
+GLIBC_2.31 __setpgid F
+GLIBC_2.31 __sigaction F
+GLIBC_2.31 __signbit F
+GLIBC_2.31 __signbitf F
+GLIBC_2.31 __signbitl F
+GLIBC_2.31 __sigpause F
+GLIBC_2.31 __sigsetjmp F
+GLIBC_2.31 __sigsuspend F
+GLIBC_2.31 __snprintf_chk F
+GLIBC_2.31 __sprintf_chk F
+GLIBC_2.31 __stack_chk_fail F
+GLIBC_2.31 __statfs F
+GLIBC_2.31 __stpcpy F
+GLIBC_2.31 __stpcpy_chk F
+GLIBC_2.31 __stpncpy F
+GLIBC_2.31 __stpncpy_chk F
+GLIBC_2.31 __strcasecmp F
+GLIBC_2.31 __strcasecmp_l F
+GLIBC_2.31 __strcasestr F
+GLIBC_2.31 __strcat_chk F
+GLIBC_2.31 __strcoll_l F
+GLIBC_2.31 __strcpy_chk F
+GLIBC_2.31 __strdup F
+GLIBC_2.31 __strerror_r F
+GLIBC_2.31 __strfmon_l F
+GLIBC_2.31 __strftime_l F
+GLIBC_2.31 __strncasecmp_l F
+GLIBC_2.31 __strncat_chk F
+GLIBC_2.31 __strncpy_chk F
+GLIBC_2.31 __strndup F
+GLIBC_2.31 __strsep_g F
+GLIBC_2.31 __strtod_internal F
+GLIBC_2.31 __strtod_l F
+GLIBC_2.31 __strtof_internal F
+GLIBC_2.31 __strtof_l F
+GLIBC_2.31 __strtok_r F
+GLIBC_2.31 __strtol_internal F
+GLIBC_2.31 __strtol_l F
+GLIBC_2.31 __strtold_internal F
+GLIBC_2.31 __strtold_l F
+GLIBC_2.31 __strtoll_internal F
+GLIBC_2.31 __strtoll_l F
+GLIBC_2.31 __strtoul_internal F
+GLIBC_2.31 __strtoul_l F
+GLIBC_2.31 __strtoull_internal F
+GLIBC_2.31 __strtoull_l F
+GLIBC_2.31 __strverscmp F
+GLIBC_2.31 __strxfrm_l F
+GLIBC_2.31 __swprintf_chk F
+GLIBC_2.31 __sysconf F
+GLIBC_2.31 __syslog_chk F
+GLIBC_2.31 __sysv_signal F
+GLIBC_2.31 __timezone D 0x4
+GLIBC_2.31 __toascii_l F
+GLIBC_2.31 __tolower_l F
+GLIBC_2.31 __toupper_l F
+GLIBC_2.31 __towctrans F
+GLIBC_2.31 __towctrans_l F
+GLIBC_2.31 __towlower_l F
+GLIBC_2.31 __towupper_l F
+GLIBC_2.31 __ttyname_r_chk F
+GLIBC_2.31 __tzname D 0x8
+GLIBC_2.31 __uflow F
+GLIBC_2.31 __underflow F
+GLIBC_2.31 __uselocale F
+GLIBC_2.31 __vasprintf_chk F
+GLIBC_2.31 __vdprintf_chk F
+GLIBC_2.31 __vfork F
+GLIBC_2.31 __vfprintf_chk F
+GLIBC_2.31 __vfscanf F
+GLIBC_2.31 __vfwprintf_chk F
+GLIBC_2.31 __vprintf_chk F
+GLIBC_2.31 __vsnprintf F
+GLIBC_2.31 __vsnprintf_chk F
+GLIBC_2.31 __vsprintf_chk F
+GLIBC_2.31 __vsscanf F
+GLIBC_2.31 __vswprintf_chk F
+GLIBC_2.31 __vsyslog_chk F
+GLIBC_2.31 __vwprintf_chk F
+GLIBC_2.31 __wait F
+GLIBC_2.31 __waitpid F
+GLIBC_2.31 __wcpcpy_chk F
+GLIBC_2.31 __wcpncpy_chk F
+GLIBC_2.31 __wcrtomb_chk F
+GLIBC_2.31 __wcscasecmp_l F
+GLIBC_2.31 __wcscat_chk F
+GLIBC_2.31 __wcscoll_l F
+GLIBC_2.31 __wcscpy_chk F
+GLIBC_2.31 __wcsftime_l F
+GLIBC_2.31 __wcsncasecmp_l F
+GLIBC_2.31 __wcsncat_chk F
+GLIBC_2.31 __wcsncpy_chk F
+GLIBC_2.31 __wcsnrtombs_chk F
+GLIBC_2.31 __wcsrtombs_chk F
+GLIBC_2.31 __wcstod_internal F
+GLIBC_2.31 __wcstod_l F
+GLIBC_2.31 __wcstof_internal F
+GLIBC_2.31 __wcstof_l F
+GLIBC_2.31 __wcstol_internal F
+GLIBC_2.31 __wcstol_l F
+GLIBC_2.31 __wcstold_internal F
+GLIBC_2.31 __wcstold_l F
+GLIBC_2.31 __wcstoll_internal F
+GLIBC_2.31 __wcstoll_l F
+GLIBC_2.31 __wcstombs_chk F
+GLIBC_2.31 __wcstoul_internal F
+GLIBC_2.31 __wcstoul_l F
+GLIBC_2.31 __wcstoull_internal F
+GLIBC_2.31 __wcstoull_l F
+GLIBC_2.31 __wcsxfrm_l F
+GLIBC_2.31 __wctomb_chk F
+GLIBC_2.31 __wctrans_l F
+GLIBC_2.31 __wctype_l F
+GLIBC_2.31 __wmemcpy_chk F
+GLIBC_2.31 __wmemmove_chk F
+GLIBC_2.31 __wmempcpy_chk F
+GLIBC_2.31 __wmemset_chk F
+GLIBC_2.31 __woverflow F
+GLIBC_2.31 __wprintf_chk F
+GLIBC_2.31 __write F
+GLIBC_2.31 __wuflow F
+GLIBC_2.31 __wunderflow F
+GLIBC_2.31 __xmknod F
+GLIBC_2.31 __xmknodat F
+GLIBC_2.31 __xpg_basename F
+GLIBC_2.31 __xpg_sigpause F
+GLIBC_2.31 __xpg_strerror_r F
+GLIBC_2.31 __xstat F
+GLIBC_2.31 __xstat64 F
+GLIBC_2.31 _authenticate F
+GLIBC_2.31 _dl_mcount_wrapper F
+GLIBC_2.31 _dl_mcount_wrapper_check F
+GLIBC_2.31 _environ D 0x4
+GLIBC_2.31 _exit F
+GLIBC_2.31 _flushlbf F
+GLIBC_2.31 _libc_intl_domainname D 0x5
+GLIBC_2.31 _longjmp F
+GLIBC_2.31 _mcleanup F
+GLIBC_2.31 _mcount F
+GLIBC_2.31 _nl_default_dirname D 0x12
+GLIBC_2.31 _nl_domain_bindings D 0x4
+GLIBC_2.31 _nl_msg_cat_cntr D 0x4
+GLIBC_2.31 _null_auth D 0xc
+GLIBC_2.31 _obstack_allocated_p F
+GLIBC_2.31 _obstack_begin F
+GLIBC_2.31 _obstack_begin_1 F
+GLIBC_2.31 _obstack_free F
+GLIBC_2.31 _obstack_memory_used F
+GLIBC_2.31 _obstack_newchunk F
+GLIBC_2.31 _res D 0x200
+GLIBC_2.31 _res_hconf D 0x30
+GLIBC_2.31 _rpc_dtablesize F
+GLIBC_2.31 _seterr_reply F
+GLIBC_2.31 _setjmp F
+GLIBC_2.31 _sys_errlist D 0x21c
+GLIBC_2.31 _sys_nerr D 0x4
+GLIBC_2.31 _sys_siglist D 0x104
+GLIBC_2.31 _tolower F
+GLIBC_2.31 _toupper F
+GLIBC_2.31 a64l F
+GLIBC_2.31 abort F
+GLIBC_2.31 abs F
+GLIBC_2.31 accept F
+GLIBC_2.31 accept4 F
+GLIBC_2.31 access F
+GLIBC_2.31 acct F
+GLIBC_2.31 addmntent F
+GLIBC_2.31 addseverity F
+GLIBC_2.31 adjtime F
+GLIBC_2.31 adjtimex F
+GLIBC_2.31 alarm F
+GLIBC_2.31 aligned_alloc F
+GLIBC_2.31 alphasort F
+GLIBC_2.31 alphasort64 F
+GLIBC_2.31 argp_err_exit_status D 0x4
+GLIBC_2.31 argp_error F
+GLIBC_2.31 argp_failure F
+GLIBC_2.31 argp_help F
+GLIBC_2.31 argp_parse F
+GLIBC_2.31 argp_program_bug_address D 0x4
+GLIBC_2.31 argp_program_version D 0x4
+GLIBC_2.31 argp_program_version_hook D 0x4
+GLIBC_2.31 argp_state_help F
+GLIBC_2.31 argp_usage F
+GLIBC_2.31 argz_add F
+GLIBC_2.31 argz_add_sep F
+GLIBC_2.31 argz_append F
+GLIBC_2.31 argz_count F
+GLIBC_2.31 argz_create F
+GLIBC_2.31 argz_create_sep F
+GLIBC_2.31 argz_delete F
+GLIBC_2.31 argz_extract F
+GLIBC_2.31 argz_insert F
+GLIBC_2.31 argz_next F
+GLIBC_2.31 argz_replace F
+GLIBC_2.31 argz_stringify F
+GLIBC_2.31 asctime F
+GLIBC_2.31 asctime_r F
+GLIBC_2.31 asprintf F
+GLIBC_2.31 atof F
+GLIBC_2.31 atoi F
+GLIBC_2.31 atol F
+GLIBC_2.31 atoll F
+GLIBC_2.31 authdes_create F
+GLIBC_2.31 authdes_getucred F
+GLIBC_2.31 authdes_pk_create F
+GLIBC_2.31 authnone_create F
+GLIBC_2.31 authunix_create F
+GLIBC_2.31 authunix_create_default F
+GLIBC_2.31 backtrace F
+GLIBC_2.31 backtrace_symbols F
+GLIBC_2.31 backtrace_symbols_fd F
+GLIBC_2.31 basename F
+GLIBC_2.31 bcmp F
+GLIBC_2.31 bcopy F
+GLIBC_2.31 bind F
+GLIBC_2.31 bind_textdomain_codeset F
+GLIBC_2.31 bindresvport F
+GLIBC_2.31 bindtextdomain F
+GLIBC_2.31 brk F
+GLIBC_2.31 bsd_signal F
+GLIBC_2.31 bsearch F
+GLIBC_2.31 btowc F
+GLIBC_2.31 bzero F
+GLIBC_2.31 c16rtomb F
+GLIBC_2.31 c32rtomb F
+GLIBC_2.31 calloc F
+GLIBC_2.31 callrpc F
+GLIBC_2.31 canonicalize_file_name F
+GLIBC_2.31 capget F
+GLIBC_2.31 capset F
+GLIBC_2.31 catclose F
+GLIBC_2.31 catgets F
+GLIBC_2.31 catopen F
+GLIBC_2.31 cbc_crypt F
+GLIBC_2.31 cfgetispeed F
+GLIBC_2.31 cfgetospeed F
+GLIBC_2.31 cfmakeraw F
+GLIBC_2.31 cfsetispeed F
+GLIBC_2.31 cfsetospeed F
+GLIBC_2.31 cfsetspeed F
+GLIBC_2.31 chdir F
+GLIBC_2.31 chflags F
+GLIBC_2.31 chmod F
+GLIBC_2.31 chown F
+GLIBC_2.31 chroot F
+GLIBC_2.31 clearenv F
+GLIBC_2.31 clearerr F
+GLIBC_2.31 clearerr_unlocked F
+GLIBC_2.31 clnt_broadcast F
+GLIBC_2.31 clnt_create F
+GLIBC_2.31 clnt_pcreateerror F
+GLIBC_2.31 clnt_perrno F
+GLIBC_2.31 clnt_perror F
+GLIBC_2.31 clnt_spcreateerror F
+GLIBC_2.31 clnt_sperrno F
+GLIBC_2.31 clnt_sperror F
+GLIBC_2.31 clntraw_create F
+GLIBC_2.31 clnttcp_create F
+GLIBC_2.31 clntudp_bufcreate F
+GLIBC_2.31 clntudp_create F
+GLIBC_2.31 clntunix_create F
+GLIBC_2.31 clock F
+GLIBC_2.31 clock_adjtime F
+GLIBC_2.31 clock_getcpuclockid F
+GLIBC_2.31 clock_getres F
+GLIBC_2.31 clock_gettime F
+GLIBC_2.31 clock_nanosleep F
+GLIBC_2.31 clock_settime F
+GLIBC_2.31 clone F
+GLIBC_2.31 close F
+GLIBC_2.31 closedir F
+GLIBC_2.31 closelog F
+GLIBC_2.31 confstr F
+GLIBC_2.31 connect F
+GLIBC_2.31 copy_file_range F
+GLIBC_2.31 copysign F
+GLIBC_2.31 copysignf F
+GLIBC_2.31 copysignl F
+GLIBC_2.31 creat F
+GLIBC_2.31 creat64 F
+GLIBC_2.31 ctermid F
+GLIBC_2.31 ctime F
+GLIBC_2.31 ctime_r F
+GLIBC_2.31 cuserid F
+GLIBC_2.31 daemon F
+GLIBC_2.31 daylight D 0x4
+GLIBC_2.31 dcgettext F
+GLIBC_2.31 dcngettext F
+GLIBC_2.31 delete_module F
+GLIBC_2.31 des_setparity F
+GLIBC_2.31 dgettext F
+GLIBC_2.31 difftime F
+GLIBC_2.31 dirfd F
+GLIBC_2.31 dirname F
+GLIBC_2.31 div F
+GLIBC_2.31 dl_iterate_phdr F
+GLIBC_2.31 dngettext F
+GLIBC_2.31 dprintf F
+GLIBC_2.31 drand48 F
+GLIBC_2.31 drand48_r F
+GLIBC_2.31 dup F
+GLIBC_2.31 dup2 F
+GLIBC_2.31 dup3 F
+GLIBC_2.31 duplocale F
+GLIBC_2.31 dysize F
+GLIBC_2.31 eaccess F
+GLIBC_2.31 ecb_crypt F
+GLIBC_2.31 ecvt F
+GLIBC_2.31 ecvt_r F
+GLIBC_2.31 endaliasent F
+GLIBC_2.31 endfsent F
+GLIBC_2.31 endgrent F
+GLIBC_2.31 endhostent F
+GLIBC_2.31 endmntent F
+GLIBC_2.31 endnetent F
+GLIBC_2.31 endnetgrent F
+GLIBC_2.31 endprotoent F
+GLIBC_2.31 endpwent F
+GLIBC_2.31 endrpcent F
+GLIBC_2.31 endservent F
+GLIBC_2.31 endsgent F
+GLIBC_2.31 endspent F
+GLIBC_2.31 endttyent F
+GLIBC_2.31 endusershell F
+GLIBC_2.31 endutent F
+GLIBC_2.31 endutxent F
+GLIBC_2.31 environ D 0x4
+GLIBC_2.31 envz_add F
+GLIBC_2.31 envz_entry F
+GLIBC_2.31 envz_get F
+GLIBC_2.31 envz_merge F
+GLIBC_2.31 envz_remove F
+GLIBC_2.31 envz_strip F
+GLIBC_2.31 epoll_create F
+GLIBC_2.31 epoll_create1 F
+GLIBC_2.31 epoll_ctl F
+GLIBC_2.31 epoll_pwait F
+GLIBC_2.31 epoll_wait F
+GLIBC_2.31 erand48 F
+GLIBC_2.31 erand48_r F
+GLIBC_2.31 err F
+GLIBC_2.31 error F
+GLIBC_2.31 error_at_line F
+GLIBC_2.31 error_message_count D 0x4
+GLIBC_2.31 error_one_per_line D 0x4
+GLIBC_2.31 error_print_progname D 0x4
+GLIBC_2.31 errx F
+GLIBC_2.31 ether_aton F
+GLIBC_2.31 ether_aton_r F
+GLIBC_2.31 ether_hostton F
+GLIBC_2.31 ether_line F
+GLIBC_2.31 ether_ntoa F
+GLIBC_2.31 ether_ntoa_r F
+GLIBC_2.31 ether_ntohost F
+GLIBC_2.31 euidaccess F
+GLIBC_2.31 eventfd F
+GLIBC_2.31 eventfd_read F
+GLIBC_2.31 eventfd_write F
+GLIBC_2.31 execl F
+GLIBC_2.31 execle F
+GLIBC_2.31 execlp F
+GLIBC_2.31 execv F
+GLIBC_2.31 execve F
+GLIBC_2.31 execvp F
+GLIBC_2.31 execvpe F
+GLIBC_2.31 exit F
+GLIBC_2.31 explicit_bzero F
+GLIBC_2.31 faccessat F
+GLIBC_2.31 fallocate F
+GLIBC_2.31 fallocate64 F
+GLIBC_2.31 fanotify_init F
+GLIBC_2.31 fanotify_mark F
+GLIBC_2.31 fchdir F
+GLIBC_2.31 fchflags F
+GLIBC_2.31 fchmod F
+GLIBC_2.31 fchmodat F
+GLIBC_2.31 fchown F
+GLIBC_2.31 fchownat F
+GLIBC_2.31 fclose F
+GLIBC_2.31 fcloseall F
+GLIBC_2.31 fcntl F
+GLIBC_2.31 fcntl64 F
+GLIBC_2.31 fcvt F
+GLIBC_2.31 fcvt_r F
+GLIBC_2.31 fdatasync F
+GLIBC_2.31 fdopen F
+GLIBC_2.31 fdopendir F
+GLIBC_2.31 feof F
+GLIBC_2.31 feof_unlocked F
+GLIBC_2.31 ferror F
+GLIBC_2.31 ferror_unlocked F
+GLIBC_2.31 fexecve F
+GLIBC_2.31 fflush F
+GLIBC_2.31 fflush_unlocked F
+GLIBC_2.31 ffs F
+GLIBC_2.31 ffsl F
+GLIBC_2.31 ffsll F
+GLIBC_2.31 fgetc F
+GLIBC_2.31 fgetc_unlocked F
+GLIBC_2.31 fgetgrent F
+GLIBC_2.31 fgetgrent_r F
+GLIBC_2.31 fgetpos F
+GLIBC_2.31 fgetpos64 F
+GLIBC_2.31 fgetpwent F
+GLIBC_2.31 fgetpwent_r F
+GLIBC_2.31 fgets F
+GLIBC_2.31 fgets_unlocked F
+GLIBC_2.31 fgetsgent F
+GLIBC_2.31 fgetsgent_r F
+GLIBC_2.31 fgetspent F
+GLIBC_2.31 fgetspent_r F
+GLIBC_2.31 fgetwc F
+GLIBC_2.31 fgetwc_unlocked F
+GLIBC_2.31 fgetws F
+GLIBC_2.31 fgetws_unlocked F
+GLIBC_2.31 fgetxattr F
+GLIBC_2.31 fileno F
+GLIBC_2.31 fileno_unlocked F
+GLIBC_2.31 finite F
+GLIBC_2.31 finitef F
+GLIBC_2.31 finitel F
+GLIBC_2.31 flistxattr F
+GLIBC_2.31 flock F
+GLIBC_2.31 flockfile F
+GLIBC_2.31 fmemopen F
+GLIBC_2.31 fmtmsg F
+GLIBC_2.31 fnmatch F
+GLIBC_2.31 fopen F
+GLIBC_2.31 fopen64 F
+GLIBC_2.31 fopencookie F
+GLIBC_2.31 fork F
+GLIBC_2.31 fpathconf F
+GLIBC_2.31 fprintf F
+GLIBC_2.31 fputc F
+GLIBC_2.31 fputc_unlocked F
+GLIBC_2.31 fputs F
+GLIBC_2.31 fputs_unlocked F
+GLIBC_2.31 fputwc F
+GLIBC_2.31 fputwc_unlocked F
+GLIBC_2.31 fputws F
+GLIBC_2.31 fputws_unlocked F
+GLIBC_2.31 fread F
+GLIBC_2.31 fread_unlocked F
+GLIBC_2.31 free F
+GLIBC_2.31 freeaddrinfo F
+GLIBC_2.31 freeifaddrs F
+GLIBC_2.31 freelocale F
+GLIBC_2.31 fremovexattr F
+GLIBC_2.31 freopen F
+GLIBC_2.31 freopen64 F
+GLIBC_2.31 frexp F
+GLIBC_2.31 frexpf F
+GLIBC_2.31 frexpl F
+GLIBC_2.31 fscanf F
+GLIBC_2.31 fseek F
+GLIBC_2.31 fseeko F
+GLIBC_2.31 fseeko64 F
+GLIBC_2.31 fsetpos F
+GLIBC_2.31 fsetpos64 F
+GLIBC_2.31 fsetxattr F
+GLIBC_2.31 fstatfs F
+GLIBC_2.31 fstatfs64 F
+GLIBC_2.31 fstatvfs F
+GLIBC_2.31 fstatvfs64 F
+GLIBC_2.31 fsync F
+GLIBC_2.31 ftell F
+GLIBC_2.31 ftello F
+GLIBC_2.31 ftello64 F
+GLIBC_2.31 ftime F
+GLIBC_2.31 ftok F
+GLIBC_2.31 ftruncate F
+GLIBC_2.31 ftruncate64 F
+GLIBC_2.31 ftrylockfile F
+GLIBC_2.31 fts64_children F
+GLIBC_2.31 fts64_close F
+GLIBC_2.31 fts64_open F
+GLIBC_2.31 fts64_read F
+GLIBC_2.31 fts64_set F
+GLIBC_2.31 fts_children F
+GLIBC_2.31 fts_close F
+GLIBC_2.31 fts_open F
+GLIBC_2.31 fts_read F
+GLIBC_2.31 fts_set F
+GLIBC_2.31 ftw F
+GLIBC_2.31 ftw64 F
+GLIBC_2.31 funlockfile F
+GLIBC_2.31 futimens F
+GLIBC_2.31 futimes F
+GLIBC_2.31 futimesat F
+GLIBC_2.31 fwide F
+GLIBC_2.31 fwprintf F
+GLIBC_2.31 fwrite F
+GLIBC_2.31 fwrite_unlocked F
+GLIBC_2.31 fwscanf F
+GLIBC_2.31 gai_strerror F
+GLIBC_2.31 gcvt F
+GLIBC_2.31 get_avphys_pages F
+GLIBC_2.31 get_current_dir_name F
+GLIBC_2.31 get_myaddress F
+GLIBC_2.31 get_nprocs F
+GLIBC_2.31 get_nprocs_conf F
+GLIBC_2.31 get_phys_pages F
+GLIBC_2.31 getaddrinfo F
+GLIBC_2.31 getaliasbyname F
+GLIBC_2.31 getaliasbyname_r F
+GLIBC_2.31 getaliasent F
+GLIBC_2.31 getaliasent_r F
+GLIBC_2.31 getauxval F
+GLIBC_2.31 getc F
+GLIBC_2.31 getc_unlocked F
+GLIBC_2.31 getchar F
+GLIBC_2.31 getchar_unlocked F
+GLIBC_2.31 getcontext F
+GLIBC_2.31 getcpu F
+GLIBC_2.31 getcwd F
+GLIBC_2.31 getdate F
+GLIBC_2.31 getdate_err D 0x4
+GLIBC_2.31 getdate_r F
+GLIBC_2.31 getdelim F
+GLIBC_2.31 getdents64 F
+GLIBC_2.31 getdirentries F
+GLIBC_2.31 getdirentries64 F
+GLIBC_2.31 getdomainname F
+GLIBC_2.31 getdtablesize F
+GLIBC_2.31 getegid F
+GLIBC_2.31 getentropy F
+GLIBC_2.31 getenv F
+GLIBC_2.31 geteuid F
+GLIBC_2.31 getfsent F
+GLIBC_2.31 getfsfile F
+GLIBC_2.31 getfsspec F
+GLIBC_2.31 getgid F
+GLIBC_2.31 getgrent F
+GLIBC_2.31 getgrent_r F
+GLIBC_2.31 getgrgid F
+GLIBC_2.31 getgrgid_r F
+GLIBC_2.31 getgrnam F
+GLIBC_2.31 getgrnam_r F
+GLIBC_2.31 getgrouplist F
+GLIBC_2.31 getgroups F
+GLIBC_2.31 gethostbyaddr F
+GLIBC_2.31 gethostbyaddr_r F
+GLIBC_2.31 gethostbyname F
+GLIBC_2.31 gethostbyname2 F
+GLIBC_2.31 gethostbyname2_r F
+GLIBC_2.31 gethostbyname_r F
+GLIBC_2.31 gethostent F
+GLIBC_2.31 gethostent_r F
+GLIBC_2.31 gethostid F
+GLIBC_2.31 gethostname F
+GLIBC_2.31 getifaddrs F
+GLIBC_2.31 getipv4sourcefilter F
+GLIBC_2.31 getitimer F
+GLIBC_2.31 getline F
+GLIBC_2.31 getloadavg F
+GLIBC_2.31 getlogin F
+GLIBC_2.31 getlogin_r F
+GLIBC_2.31 getmntent F
+GLIBC_2.31 getmntent_r F
+GLIBC_2.31 getnameinfo F
+GLIBC_2.31 getnetbyaddr F
+GLIBC_2.31 getnetbyaddr_r F
+GLIBC_2.31 getnetbyname F
+GLIBC_2.31 getnetbyname_r F
+GLIBC_2.31 getnetent F
+GLIBC_2.31 getnetent_r F
+GLIBC_2.31 getnetgrent F
+GLIBC_2.31 getnetgrent_r F
+GLIBC_2.31 getnetname F
+GLIBC_2.31 getopt F
+GLIBC_2.31 getopt_long F
+GLIBC_2.31 getopt_long_only F
+GLIBC_2.31 getpagesize F
+GLIBC_2.31 getpass F
+GLIBC_2.31 getpeername F
+GLIBC_2.31 getpgid F
+GLIBC_2.31 getpgrp F
+GLIBC_2.31 getpid F
+GLIBC_2.31 getppid F
+GLIBC_2.31 getpriority F
+GLIBC_2.31 getprotobyname F
+GLIBC_2.31 getprotobyname_r F
+GLIBC_2.31 getprotobynumber F
+GLIBC_2.31 getprotobynumber_r F
+GLIBC_2.31 getprotoent F
+GLIBC_2.31 getprotoent_r F
+GLIBC_2.31 getpt F
+GLIBC_2.31 getpublickey F
+GLIBC_2.31 getpw F
+GLIBC_2.31 getpwent F
+GLIBC_2.31 getpwent_r F
+GLIBC_2.31 getpwnam F
+GLIBC_2.31 getpwnam_r F
+GLIBC_2.31 getpwuid F
+GLIBC_2.31 getpwuid_r F
+GLIBC_2.31 getrandom F
+GLIBC_2.31 getresgid F
+GLIBC_2.31 getresuid F
+GLIBC_2.31 getrlimit F
+GLIBC_2.31 getrlimit64 F
+GLIBC_2.31 getrpcbyname F
+GLIBC_2.31 getrpcbyname_r F
+GLIBC_2.31 getrpcbynumber F
+GLIBC_2.31 getrpcbynumber_r F
+GLIBC_2.31 getrpcent F
+GLIBC_2.31 getrpcent_r F
+GLIBC_2.31 getrpcport F
+GLIBC_2.31 getrusage F
+GLIBC_2.31 gets F
+GLIBC_2.31 getsecretkey F
+GLIBC_2.31 getservbyname F
+GLIBC_2.31 getservbyname_r F
+GLIBC_2.31 getservbyport F
+GLIBC_2.31 getservbyport_r F
+GLIBC_2.31 getservent F
+GLIBC_2.31 getservent_r F
+GLIBC_2.31 getsgent F
+GLIBC_2.31 getsgent_r F
+GLIBC_2.31 getsgnam F
+GLIBC_2.31 getsgnam_r F
+GLIBC_2.31 getsid F
+GLIBC_2.31 getsockname F
+GLIBC_2.31 getsockopt F
+GLIBC_2.31 getsourcefilter F
+GLIBC_2.31 getspent F
+GLIBC_2.31 getspent_r F
+GLIBC_2.31 getspnam F
+GLIBC_2.31 getspnam_r F
+GLIBC_2.31 getsubopt F
+GLIBC_2.31 gettext F
+GLIBC_2.31 gettid F
+GLIBC_2.31 gettimeofday F
+GLIBC_2.31 getttyent F
+GLIBC_2.31 getttynam F
+GLIBC_2.31 getuid F
+GLIBC_2.31 getusershell F
+GLIBC_2.31 getutent F
+GLIBC_2.31 getutent_r F
+GLIBC_2.31 getutid F
+GLIBC_2.31 getutid_r F
+GLIBC_2.31 getutline F
+GLIBC_2.31 getutline_r F
+GLIBC_2.31 getutmp F
+GLIBC_2.31 getutmpx F
+GLIBC_2.31 getutxent F
+GLIBC_2.31 getutxid F
+GLIBC_2.31 getutxline F
+GLIBC_2.31 getw F
+GLIBC_2.31 getwc F
+GLIBC_2.31 getwc_unlocked F
+GLIBC_2.31 getwchar F
+GLIBC_2.31 getwchar_unlocked F
+GLIBC_2.31 getwd F
+GLIBC_2.31 getxattr F
+GLIBC_2.31 glob F
+GLIBC_2.31 glob64 F
+GLIBC_2.31 glob_pattern_p F
+GLIBC_2.31 globfree F
+GLIBC_2.31 globfree64 F
+GLIBC_2.31 gmtime F
+GLIBC_2.31 gmtime_r F
+GLIBC_2.31 gnu_dev_major F
+GLIBC_2.31 gnu_dev_makedev F
+GLIBC_2.31 gnu_dev_minor F
+GLIBC_2.31 gnu_get_libc_release F
+GLIBC_2.31 gnu_get_libc_version F
+GLIBC_2.31 grantpt F
+GLIBC_2.31 group_member F
+GLIBC_2.31 gsignal F
+GLIBC_2.31 gtty F
+GLIBC_2.31 h_errlist D 0x14
+GLIBC_2.31 h_nerr D 0x4
+GLIBC_2.31 hasmntopt F
+GLIBC_2.31 hcreate F
+GLIBC_2.31 hcreate_r F
+GLIBC_2.31 hdestroy F
+GLIBC_2.31 hdestroy_r F
+GLIBC_2.31 herror F
+GLIBC_2.31 host2netname F
+GLIBC_2.31 hsearch F
+GLIBC_2.31 hsearch_r F
+GLIBC_2.31 hstrerror F
+GLIBC_2.31 htonl F
+GLIBC_2.31 htons F
+GLIBC_2.31 iconv F
+GLIBC_2.31 iconv_close F
+GLIBC_2.31 iconv_open F
+GLIBC_2.31 if_freenameindex F
+GLIBC_2.31 if_indextoname F
+GLIBC_2.31 if_nameindex F
+GLIBC_2.31 if_nametoindex F
+GLIBC_2.31 imaxabs F
+GLIBC_2.31 imaxdiv F
+GLIBC_2.31 in6addr_any D 0x10
+GLIBC_2.31 in6addr_loopback D 0x10
+GLIBC_2.31 index F
+GLIBC_2.31 inet6_opt_append F
+GLIBC_2.31 inet6_opt_find F
+GLIBC_2.31 inet6_opt_finish F
+GLIBC_2.31 inet6_opt_get_val F
+GLIBC_2.31 inet6_opt_init F
+GLIBC_2.31 inet6_opt_next F
+GLIBC_2.31 inet6_opt_set_val F
+GLIBC_2.31 inet6_option_alloc F
+GLIBC_2.31 inet6_option_append F
+GLIBC_2.31 inet6_option_find F
+GLIBC_2.31 inet6_option_init F
+GLIBC_2.31 inet6_option_next F
+GLIBC_2.31 inet6_option_space F
+GLIBC_2.31 inet6_rth_add F
+GLIBC_2.31 inet6_rth_getaddr F
+GLIBC_2.31 inet6_rth_init F
+GLIBC_2.31 inet6_rth_reverse F
+GLIBC_2.31 inet6_rth_segments F
+GLIBC_2.31 inet6_rth_space F
+GLIBC_2.31 inet_addr F
+GLIBC_2.31 inet_aton F
+GLIBC_2.31 inet_lnaof F
+GLIBC_2.31 inet_makeaddr F
+GLIBC_2.31 inet_netof F
+GLIBC_2.31 inet_network F
+GLIBC_2.31 inet_nsap_addr F
+GLIBC_2.31 inet_nsap_ntoa F
+GLIBC_2.31 inet_ntoa F
+GLIBC_2.31 inet_ntop F
+GLIBC_2.31 inet_pton F
+GLIBC_2.31 init_module F
+GLIBC_2.31 initgroups F
+GLIBC_2.31 initstate F
+GLIBC_2.31 initstate_r F
+GLIBC_2.31 innetgr F
+GLIBC_2.31 inotify_add_watch F
+GLIBC_2.31 inotify_init F
+GLIBC_2.31 inotify_init1 F
+GLIBC_2.31 inotify_rm_watch F
+GLIBC_2.31 insque F
+GLIBC_2.31 ioctl F
+GLIBC_2.31 iruserok F
+GLIBC_2.31 iruserok_af F
+GLIBC_2.31 isalnum F
+GLIBC_2.31 isalnum_l F
+GLIBC_2.31 isalpha F
+GLIBC_2.31 isalpha_l F
+GLIBC_2.31 isascii F
+GLIBC_2.31 isatty F
+GLIBC_2.31 isblank F
+GLIBC_2.31 isblank_l F
+GLIBC_2.31 iscntrl F
+GLIBC_2.31 iscntrl_l F
+GLIBC_2.31 isctype F
+GLIBC_2.31 isdigit F
+GLIBC_2.31 isdigit_l F
+GLIBC_2.31 isfdtype F
+GLIBC_2.31 isgraph F
+GLIBC_2.31 isgraph_l F
+GLIBC_2.31 isinf F
+GLIBC_2.31 isinff F
+GLIBC_2.31 isinfl F
+GLIBC_2.31 islower F
+GLIBC_2.31 islower_l F
+GLIBC_2.31 isnan F
+GLIBC_2.31 isnanf F
+GLIBC_2.31 isnanl F
+GLIBC_2.31 isprint F
+GLIBC_2.31 isprint_l F
+GLIBC_2.31 ispunct F
+GLIBC_2.31 ispunct_l F
+GLIBC_2.31 isspace F
+GLIBC_2.31 isspace_l F
+GLIBC_2.31 isupper F
+GLIBC_2.31 isupper_l F
+GLIBC_2.31 iswalnum F
+GLIBC_2.31 iswalnum_l F
+GLIBC_2.31 iswalpha F
+GLIBC_2.31 iswalpha_l F
+GLIBC_2.31 iswblank F
+GLIBC_2.31 iswblank_l F
+GLIBC_2.31 iswcntrl F
+GLIBC_2.31 iswcntrl_l F
+GLIBC_2.31 iswctype F
+GLIBC_2.31 iswctype_l F
+GLIBC_2.31 iswdigit F
+GLIBC_2.31 iswdigit_l F
+GLIBC_2.31 iswgraph F
+GLIBC_2.31 iswgraph_l F
+GLIBC_2.31 iswlower F
+GLIBC_2.31 iswlower_l F
+GLIBC_2.31 iswprint F
+GLIBC_2.31 iswprint_l F
+GLIBC_2.31 iswpunct F
+GLIBC_2.31 iswpunct_l F
+GLIBC_2.31 iswspace F
+GLIBC_2.31 iswspace_l F
+GLIBC_2.31 iswupper F
+GLIBC_2.31 iswupper_l F
+GLIBC_2.31 iswxdigit F
+GLIBC_2.31 iswxdigit_l F
+GLIBC_2.31 isxdigit F
+GLIBC_2.31 isxdigit_l F
+GLIBC_2.31 jrand48 F
+GLIBC_2.31 jrand48_r F
+GLIBC_2.31 key_decryptsession F
+GLIBC_2.31 key_decryptsession_pk F
+GLIBC_2.31 key_encryptsession F
+GLIBC_2.31 key_encryptsession_pk F
+GLIBC_2.31 key_gendes F
+GLIBC_2.31 key_get_conv F
+GLIBC_2.31 key_secretkey_is_set F
+GLIBC_2.31 key_setnet F
+GLIBC_2.31 key_setsecret F
+GLIBC_2.31 kill F
+GLIBC_2.31 killpg F
+GLIBC_2.31 klogctl F
+GLIBC_2.31 l64a F
+GLIBC_2.31 labs F
+GLIBC_2.31 lchmod F
+GLIBC_2.31 lchown F
+GLIBC_2.31 lckpwdf F
+GLIBC_2.31 lcong48 F
+GLIBC_2.31 lcong48_r F
+GLIBC_2.31 ldexp F
+GLIBC_2.31 ldexpf F
+GLIBC_2.31 ldexpl F
+GLIBC_2.31 ldiv F
+GLIBC_2.31 lfind F
+GLIBC_2.31 lgetxattr F
+GLIBC_2.31 link F
+GLIBC_2.31 linkat F
+GLIBC_2.31 listen F
+GLIBC_2.31 listxattr F
+GLIBC_2.31 llabs F
+GLIBC_2.31 lldiv F
+GLIBC_2.31 llistxattr F
+GLIBC_2.31 localeconv F
+GLIBC_2.31 localtime F
+GLIBC_2.31 localtime_r F
+GLIBC_2.31 lockf F
+GLIBC_2.31 lockf64 F
+GLIBC_2.31 longjmp F
+GLIBC_2.31 lrand48 F
+GLIBC_2.31 lrand48_r F
+GLIBC_2.31 lremovexattr F
+GLIBC_2.31 lsearch F
+GLIBC_2.31 lseek F
+GLIBC_2.31 lseek64 F
+GLIBC_2.31 lsetxattr F
+GLIBC_2.31 lutimes F
+GLIBC_2.31 madvise F
+GLIBC_2.31 makecontext F
+GLIBC_2.31 mallinfo F
+GLIBC_2.31 malloc F
+GLIBC_2.31 malloc_info F
+GLIBC_2.31 malloc_stats F
+GLIBC_2.31 malloc_trim F
+GLIBC_2.31 malloc_usable_size F
+GLIBC_2.31 mallopt F
+GLIBC_2.31 mallwatch D 0x4
+GLIBC_2.31 mblen F
+GLIBC_2.31 mbrlen F
+GLIBC_2.31 mbrtoc16 F
+GLIBC_2.31 mbrtoc32 F
+GLIBC_2.31 mbrtowc F
+GLIBC_2.31 mbsinit F
+GLIBC_2.31 mbsnrtowcs F
+GLIBC_2.31 mbsrtowcs F
+GLIBC_2.31 mbstowcs F
+GLIBC_2.31 mbtowc F
+GLIBC_2.31 mcheck F
+GLIBC_2.31 mcheck_check_all F
+GLIBC_2.31 mcheck_pedantic F
+GLIBC_2.31 memalign F
+GLIBC_2.31 memccpy F
+GLIBC_2.31 memchr F
+GLIBC_2.31 memcmp F
+GLIBC_2.31 memcpy F
+GLIBC_2.31 memfd_create F
+GLIBC_2.31 memfrob F
+GLIBC_2.31 memmem F
+GLIBC_2.31 memmove F
+GLIBC_2.31 mempcpy F
+GLIBC_2.31 memrchr F
+GLIBC_2.31 memset F
+GLIBC_2.31 mincore F
+GLIBC_2.31 mkdir F
+GLIBC_2.31 mkdirat F
+GLIBC_2.31 mkdtemp F
+GLIBC_2.31 mkfifo F
+GLIBC_2.31 mkfifoat F
+GLIBC_2.31 mkostemp F
+GLIBC_2.31 mkostemp64 F
+GLIBC_2.31 mkostemps F
+GLIBC_2.31 mkostemps64 F
+GLIBC_2.31 mkstemp F
+GLIBC_2.31 mkstemp64 F
+GLIBC_2.31 mkstemps F
+GLIBC_2.31 mkstemps64 F
+GLIBC_2.31 mktemp F
+GLIBC_2.31 mktime F
+GLIBC_2.31 mlock F
+GLIBC_2.31 mlock2 F
+GLIBC_2.31 mlockall F
+GLIBC_2.31 mmap F
+GLIBC_2.31 mmap64 F
+GLIBC_2.31 modf F
+GLIBC_2.31 modff F
+GLIBC_2.31 modfl F
+GLIBC_2.31 moncontrol F
+GLIBC_2.31 monstartup F
+GLIBC_2.31 mount F
+GLIBC_2.31 mprobe F
+GLIBC_2.31 mprotect F
+GLIBC_2.31 mrand48 F
+GLIBC_2.31 mrand48_r F
+GLIBC_2.31 mremap F
+GLIBC_2.31 msgctl F
+GLIBC_2.31 msgget F
+GLIBC_2.31 msgrcv F
+GLIBC_2.31 msgsnd F
+GLIBC_2.31 msync F
+GLIBC_2.31 mtrace F
+GLIBC_2.31 munlock F
+GLIBC_2.31 munlockall F
+GLIBC_2.31 munmap F
+GLIBC_2.31 muntrace F
+GLIBC_2.31 name_to_handle_at F
+GLIBC_2.31 nanosleep F
+GLIBC_2.31 netname2host F
+GLIBC_2.31 netname2user F
+GLIBC_2.31 newlocale F
+GLIBC_2.31 nftw F
+GLIBC_2.31 nftw64 F
+GLIBC_2.31 ngettext F
+GLIBC_2.31 nice F
+GLIBC_2.31 nl_langinfo F
+GLIBC_2.31 nl_langinfo_l F
+GLIBC_2.31 nrand48 F
+GLIBC_2.31 nrand48_r F
+GLIBC_2.31 ntohl F
+GLIBC_2.31 ntohs F
+GLIBC_2.31 ntp_adjtime F
+GLIBC_2.31 ntp_gettime F
+GLIBC_2.31 ntp_gettimex F
+GLIBC_2.31 obstack_alloc_failed_handler D 0x4
+GLIBC_2.31 obstack_exit_failure D 0x4
+GLIBC_2.31 obstack_free F
+GLIBC_2.31 obstack_printf F
+GLIBC_2.31 obstack_vprintf F
+GLIBC_2.31 on_exit F
+GLIBC_2.31 open F
+GLIBC_2.31 open64 F
+GLIBC_2.31 open_by_handle_at F
+GLIBC_2.31 open_memstream F
+GLIBC_2.31 open_wmemstream F
+GLIBC_2.31 openat F
+GLIBC_2.31 openat64 F
+GLIBC_2.31 opendir F
+GLIBC_2.31 openlog F
+GLIBC_2.31 optarg D 0x4
+GLIBC_2.31 opterr D 0x4
+GLIBC_2.31 optind D 0x4
+GLIBC_2.31 optopt D 0x4
+GLIBC_2.31 parse_printf_format F
+GLIBC_2.31 passwd2des F
+GLIBC_2.31 pathconf F
+GLIBC_2.31 pause F
+GLIBC_2.31 pclose F
+GLIBC_2.31 perror F
+GLIBC_2.31 personality F
+GLIBC_2.31 pipe F
+GLIBC_2.31 pipe2 F
+GLIBC_2.31 pivot_root F
+GLIBC_2.31 pkey_alloc F
+GLIBC_2.31 pkey_free F
+GLIBC_2.31 pkey_get F
+GLIBC_2.31 pkey_mprotect F
+GLIBC_2.31 pkey_set F
+GLIBC_2.31 pmap_getmaps F
+GLIBC_2.31 pmap_getport F
+GLIBC_2.31 pmap_rmtcall F
+GLIBC_2.31 pmap_set F
+GLIBC_2.31 pmap_unset F
+GLIBC_2.31 poll F
+GLIBC_2.31 popen F
+GLIBC_2.31 posix_fadvise F
+GLIBC_2.31 posix_fadvise64 F
+GLIBC_2.31 posix_fallocate F
+GLIBC_2.31 posix_fallocate64 F
+GLIBC_2.31 posix_madvise F
+GLIBC_2.31 posix_memalign F
+GLIBC_2.31 posix_openpt F
+GLIBC_2.31 posix_spawn F
+GLIBC_2.31 posix_spawn_file_actions_addchdir_np F
+GLIBC_2.31 posix_spawn_file_actions_addclose F
+GLIBC_2.31 posix_spawn_file_actions_adddup2 F
+GLIBC_2.31 posix_spawn_file_actions_addfchdir_np F
+GLIBC_2.31 posix_spawn_file_actions_addopen F
+GLIBC_2.31 posix_spawn_file_actions_destroy F
+GLIBC_2.31 posix_spawn_file_actions_init F
+GLIBC_2.31 posix_spawnattr_destroy F
+GLIBC_2.31 posix_spawnattr_getflags F
+GLIBC_2.31 posix_spawnattr_getpgroup F
+GLIBC_2.31 posix_spawnattr_getschedparam F
+GLIBC_2.31 posix_spawnattr_getschedpolicy F
+GLIBC_2.31 posix_spawnattr_getsigdefault F
+GLIBC_2.31 posix_spawnattr_getsigmask F
+GLIBC_2.31 posix_spawnattr_init F
+GLIBC_2.31 posix_spawnattr_setflags F
+GLIBC_2.31 posix_spawnattr_setpgroup F
+GLIBC_2.31 posix_spawnattr_setschedparam F
+GLIBC_2.31 posix_spawnattr_setschedpolicy F
+GLIBC_2.31 posix_spawnattr_setsigdefault F
+GLIBC_2.31 posix_spawnattr_setsigmask F
+GLIBC_2.31 posix_spawnp F
+GLIBC_2.31 ppoll F
+GLIBC_2.31 prctl F
+GLIBC_2.31 pread F
+GLIBC_2.31 pread64 F
+GLIBC_2.31 preadv F
+GLIBC_2.31 preadv2 F
+GLIBC_2.31 preadv64 F
+GLIBC_2.31 preadv64v2 F
+GLIBC_2.31 printf F
+GLIBC_2.31 printf_size F
+GLIBC_2.31 printf_size_info F
+GLIBC_2.31 prlimit F
+GLIBC_2.31 prlimit64 F
+GLIBC_2.31 process_vm_readv F
+GLIBC_2.31 process_vm_writev F
+GLIBC_2.31 profil F
+GLIBC_2.31 program_invocation_name D 0x4
+GLIBC_2.31 program_invocation_short_name D 0x4
+GLIBC_2.31 pselect F
+GLIBC_2.31 psiginfo F
+GLIBC_2.31 psignal F
+GLIBC_2.31 pthread_attr_destroy F
+GLIBC_2.31 pthread_attr_getdetachstate F
+GLIBC_2.31 pthread_attr_getinheritsched F
+GLIBC_2.31 pthread_attr_getschedparam F
+GLIBC_2.31 pthread_attr_getschedpolicy F
+GLIBC_2.31 pthread_attr_getscope F
+GLIBC_2.31 pthread_attr_init F
+GLIBC_2.31 pthread_attr_setdetachstate F
+GLIBC_2.31 pthread_attr_setinheritsched F
+GLIBC_2.31 pthread_attr_setschedparam F
+GLIBC_2.31 pthread_attr_setschedpolicy F
+GLIBC_2.31 pthread_attr_setscope F
+GLIBC_2.31 pthread_cond_broadcast F
+GLIBC_2.31 pthread_cond_destroy F
+GLIBC_2.31 pthread_cond_init F
+GLIBC_2.31 pthread_cond_signal F
+GLIBC_2.31 pthread_cond_timedwait F
+GLIBC_2.31 pthread_cond_wait F
+GLIBC_2.31 pthread_condattr_destroy F
+GLIBC_2.31 pthread_condattr_init F
+GLIBC_2.31 pthread_equal F
+GLIBC_2.31 pthread_exit F
+GLIBC_2.31 pthread_getschedparam F
+GLIBC_2.31 pthread_mutex_destroy F
+GLIBC_2.31 pthread_mutex_init F
+GLIBC_2.31 pthread_mutex_lock F
+GLIBC_2.31 pthread_mutex_unlock F
+GLIBC_2.31 pthread_self F
+GLIBC_2.31 pthread_setcancelstate F
+GLIBC_2.31 pthread_setcanceltype F
+GLIBC_2.31 pthread_setschedparam F
+GLIBC_2.31 ptrace F
+GLIBC_2.31 ptsname F
+GLIBC_2.31 ptsname_r F
+GLIBC_2.31 putc F
+GLIBC_2.31 putc_unlocked F
+GLIBC_2.31 putchar F
+GLIBC_2.31 putchar_unlocked F
+GLIBC_2.31 putenv F
+GLIBC_2.31 putgrent F
+GLIBC_2.31 putpwent F
+GLIBC_2.31 puts F
+GLIBC_2.31 putsgent F
+GLIBC_2.31 putspent F
+GLIBC_2.31 pututline F
+GLIBC_2.31 pututxline F
+GLIBC_2.31 putw F
+GLIBC_2.31 putwc F
+GLIBC_2.31 putwc_unlocked F
+GLIBC_2.31 putwchar F
+GLIBC_2.31 putwchar_unlocked F
+GLIBC_2.31 pvalloc F
+GLIBC_2.31 pwrite F
+GLIBC_2.31 pwrite64 F
+GLIBC_2.31 pwritev F
+GLIBC_2.31 pwritev2 F
+GLIBC_2.31 pwritev64 F
+GLIBC_2.31 pwritev64v2 F
+GLIBC_2.31 qecvt F
+GLIBC_2.31 qecvt_r F
+GLIBC_2.31 qfcvt F
+GLIBC_2.31 qfcvt_r F
+GLIBC_2.31 qgcvt F
+GLIBC_2.31 qsort F
+GLIBC_2.31 qsort_r F
+GLIBC_2.31 quick_exit F
+GLIBC_2.31 quotactl F
+GLIBC_2.31 raise F
+GLIBC_2.31 rand F
+GLIBC_2.31 rand_r F
+GLIBC_2.31 random F
+GLIBC_2.31 random_r F
+GLIBC_2.31 rawmemchr F
+GLIBC_2.31 rcmd F
+GLIBC_2.31 rcmd_af F
+GLIBC_2.31 re_comp F
+GLIBC_2.31 re_compile_fastmap F
+GLIBC_2.31 re_compile_pattern F
+GLIBC_2.31 re_exec F
+GLIBC_2.31 re_match F
+GLIBC_2.31 re_match_2 F
+GLIBC_2.31 re_search F
+GLIBC_2.31 re_search_2 F
+GLIBC_2.31 re_set_registers F
+GLIBC_2.31 re_set_syntax F
+GLIBC_2.31 re_syntax_options D 0x4
+GLIBC_2.31 read F
+GLIBC_2.31 readahead F
+GLIBC_2.31 readdir F
+GLIBC_2.31 readdir64 F
+GLIBC_2.31 readdir64_r F
+GLIBC_2.31 readdir_r F
+GLIBC_2.31 readlink F
+GLIBC_2.31 readlinkat F
+GLIBC_2.31 readv F
+GLIBC_2.31 realloc F
+GLIBC_2.31 reallocarray F
+GLIBC_2.31 realpath F
+GLIBC_2.31 reboot F
+GLIBC_2.31 recv F
+GLIBC_2.31 recvfrom F
+GLIBC_2.31 recvmmsg F
+GLIBC_2.31 recvmsg F
+GLIBC_2.31 regcomp F
+GLIBC_2.31 regerror F
+GLIBC_2.31 regexec F
+GLIBC_2.31 regfree F
+GLIBC_2.31 register_printf_function F
+GLIBC_2.31 register_printf_modifier F
+GLIBC_2.31 register_printf_specifier F
+GLIBC_2.31 register_printf_type F
+GLIBC_2.31 registerrpc F
+GLIBC_2.31 remap_file_pages F
+GLIBC_2.31 remove F
+GLIBC_2.31 removexattr F
+GLIBC_2.31 remque F
+GLIBC_2.31 rename F
+GLIBC_2.31 renameat F
+GLIBC_2.31 renameat2 F
+GLIBC_2.31 revoke F
+GLIBC_2.31 rewind F
+GLIBC_2.31 rewinddir F
+GLIBC_2.31 rexec F
+GLIBC_2.31 rexec_af F
+GLIBC_2.31 rexecoptions D 0x4
+GLIBC_2.31 rindex F
+GLIBC_2.31 rmdir F
+GLIBC_2.31 rpc_createerr D 0x10
+GLIBC_2.31 rpmatch F
+GLIBC_2.31 rresvport F
+GLIBC_2.31 rresvport_af F
+GLIBC_2.31 rtime F
+GLIBC_2.31 ruserok F
+GLIBC_2.31 ruserok_af F
+GLIBC_2.31 ruserpass F
+GLIBC_2.31 sbrk F
+GLIBC_2.31 scalbn F
+GLIBC_2.31 scalbnf F
+GLIBC_2.31 scalbnl F
+GLIBC_2.31 scandir F
+GLIBC_2.31 scandir64 F
+GLIBC_2.31 scandirat F
+GLIBC_2.31 scandirat64 F
+GLIBC_2.31 scanf F
+GLIBC_2.31 sched_get_priority_max F
+GLIBC_2.31 sched_get_priority_min F
+GLIBC_2.31 sched_getaffinity F
+GLIBC_2.31 sched_getcpu F
+GLIBC_2.31 sched_getparam F
+GLIBC_2.31 sched_getscheduler F
+GLIBC_2.31 sched_rr_get_interval F
+GLIBC_2.31 sched_setaffinity F
+GLIBC_2.31 sched_setparam F
+GLIBC_2.31 sched_setscheduler F
+GLIBC_2.31 sched_yield F
+GLIBC_2.31 secure_getenv F
+GLIBC_2.31 seed48 F
+GLIBC_2.31 seed48_r F
+GLIBC_2.31 seekdir F
+GLIBC_2.31 select F
+GLIBC_2.31 semctl F
+GLIBC_2.31 semget F
+GLIBC_2.31 semop F
+GLIBC_2.31 semtimedop F
+GLIBC_2.31 send F
+GLIBC_2.31 sendfile F
+GLIBC_2.31 sendfile64 F
+GLIBC_2.31 sendmmsg F
+GLIBC_2.31 sendmsg F
+GLIBC_2.31 sendto F
+GLIBC_2.31 setaliasent F
+GLIBC_2.31 setbuf F
+GLIBC_2.31 setbuffer F
+GLIBC_2.31 setcontext F
+GLIBC_2.31 setdomainname F
+GLIBC_2.31 setegid F
+GLIBC_2.31 setenv F
+GLIBC_2.31 seteuid F
+GLIBC_2.31 setfsent F
+GLIBC_2.31 setfsgid F
+GLIBC_2.31 setfsuid F
+GLIBC_2.31 setgid F
+GLIBC_2.31 setgrent F
+GLIBC_2.31 setgroups F
+GLIBC_2.31 sethostent F
+GLIBC_2.31 sethostid F
+GLIBC_2.31 sethostname F
+GLIBC_2.31 setipv4sourcefilter F
+GLIBC_2.31 setitimer F
+GLIBC_2.31 setjmp F
+GLIBC_2.31 setlinebuf F
+GLIBC_2.31 setlocale F
+GLIBC_2.31 setlogin F
+GLIBC_2.31 setlogmask F
+GLIBC_2.31 setmntent F
+GLIBC_2.31 setnetent F
+GLIBC_2.31 setnetgrent F
+GLIBC_2.31 setns F
+GLIBC_2.31 setpgid F
+GLIBC_2.31 setpgrp F
+GLIBC_2.31 setpriority F
+GLIBC_2.31 setprotoent F
+GLIBC_2.31 setpwent F
+GLIBC_2.31 setregid F
+GLIBC_2.31 setresgid F
+GLIBC_2.31 setresuid F
+GLIBC_2.31 setreuid F
+GLIBC_2.31 setrlimit F
+GLIBC_2.31 setrlimit64 F
+GLIBC_2.31 setrpcent F
+GLIBC_2.31 setservent F
+GLIBC_2.31 setsgent F
+GLIBC_2.31 setsid F
+GLIBC_2.31 setsockopt F
+GLIBC_2.31 setsourcefilter F
+GLIBC_2.31 setspent F
+GLIBC_2.31 setstate F
+GLIBC_2.31 setstate_r F
+GLIBC_2.31 settimeofday F
+GLIBC_2.31 setttyent F
+GLIBC_2.31 setuid F
+GLIBC_2.31 setusershell F
+GLIBC_2.31 setutent F
+GLIBC_2.31 setutxent F
+GLIBC_2.31 setvbuf F
+GLIBC_2.31 setxattr F
+GLIBC_2.31 sgetsgent F
+GLIBC_2.31 sgetsgent_r F
+GLIBC_2.31 sgetspent F
+GLIBC_2.31 sgetspent_r F
+GLIBC_2.31 shmat F
+GLIBC_2.31 shmctl F
+GLIBC_2.31 shmdt F
+GLIBC_2.31 shmget F
+GLIBC_2.31 shutdown F
+GLIBC_2.31 sigaction F
+GLIBC_2.31 sigaddset F
+GLIBC_2.31 sigaltstack F
+GLIBC_2.31 sigandset F
+GLIBC_2.31 sigblock F
+GLIBC_2.31 sigdelset F
+GLIBC_2.31 sigemptyset F
+GLIBC_2.31 sigfillset F
+GLIBC_2.31 siggetmask F
+GLIBC_2.31 sighold F
+GLIBC_2.31 sigignore F
+GLIBC_2.31 siginterrupt F
+GLIBC_2.31 sigisemptyset F
+GLIBC_2.31 sigismember F
+GLIBC_2.31 siglongjmp F
+GLIBC_2.31 signal F
+GLIBC_2.31 signalfd F
+GLIBC_2.31 sigorset F
+GLIBC_2.31 sigpause F
+GLIBC_2.31 sigpending F
+GLIBC_2.31 sigprocmask F
+GLIBC_2.31 sigqueue F
+GLIBC_2.31 sigrelse F
+GLIBC_2.31 sigreturn F
+GLIBC_2.31 sigset F
+GLIBC_2.31 sigsetmask F
+GLIBC_2.31 sigstack F
+GLIBC_2.31 sigsuspend F
+GLIBC_2.31 sigtimedwait F
+GLIBC_2.31 sigwait F
+GLIBC_2.31 sigwaitinfo F
+GLIBC_2.31 sleep F
+GLIBC_2.31 snprintf F
+GLIBC_2.31 sockatmark F
+GLIBC_2.31 socket F
+GLIBC_2.31 socketpair F
+GLIBC_2.31 splice F
+GLIBC_2.31 sprintf F
+GLIBC_2.31 sprofil F
+GLIBC_2.31 srand F
+GLIBC_2.31 srand48 F
+GLIBC_2.31 srand48_r F
+GLIBC_2.31 srandom F
+GLIBC_2.31 srandom_r F
+GLIBC_2.31 sscanf F
+GLIBC_2.31 ssignal F
+GLIBC_2.31 sstk F
+GLIBC_2.31 statfs F
+GLIBC_2.31 statfs64 F
+GLIBC_2.31 statvfs F
+GLIBC_2.31 statvfs64 F
+GLIBC_2.31 statx F
+GLIBC_2.31 stderr D 0x4
+GLIBC_2.31 stdin D 0x4
+GLIBC_2.31 stdout D 0x4
+GLIBC_2.31 stpcpy F
+GLIBC_2.31 stpncpy F
+GLIBC_2.31 strcasecmp F
+GLIBC_2.31 strcasecmp_l F
+GLIBC_2.31 strcasestr F
+GLIBC_2.31 strcat F
+GLIBC_2.31 strchr F
+GLIBC_2.31 strchrnul F
+GLIBC_2.31 strcmp F
+GLIBC_2.31 strcoll F
+GLIBC_2.31 strcoll_l F
+GLIBC_2.31 strcpy F
+GLIBC_2.31 strcspn F
+GLIBC_2.31 strdup F
+GLIBC_2.31 strerror F
+GLIBC_2.31 strerror_l F
+GLIBC_2.31 strerror_r F
+GLIBC_2.31 strfmon F
+GLIBC_2.31 strfmon_l F
+GLIBC_2.31 strfromd F
+GLIBC_2.31 strfromf F
+GLIBC_2.31 strfromf128 F
+GLIBC_2.31 strfromf32 F
+GLIBC_2.31 strfromf32x F
+GLIBC_2.31 strfromf64 F
+GLIBC_2.31 strfromf64x F
+GLIBC_2.31 strfroml F
+GLIBC_2.31 strfry F
+GLIBC_2.31 strftime F
+GLIBC_2.31 strftime_l F
+GLIBC_2.31 strlen F
+GLIBC_2.31 strncasecmp F
+GLIBC_2.31 strncasecmp_l F
+GLIBC_2.31 strncat F
+GLIBC_2.31 strncmp F
+GLIBC_2.31 strncpy F
+GLIBC_2.31 strndup F
+GLIBC_2.31 strnlen F
+GLIBC_2.31 strpbrk F
+GLIBC_2.31 strptime F
+GLIBC_2.31 strptime_l F
+GLIBC_2.31 strrchr F
+GLIBC_2.31 strsep F
+GLIBC_2.31 strsignal F
+GLIBC_2.31 strspn F
+GLIBC_2.31 strstr F
+GLIBC_2.31 strtod F
+GLIBC_2.31 strtod_l F
+GLIBC_2.31 strtof F
+GLIBC_2.31 strtof128 F
+GLIBC_2.31 strtof128_l F
+GLIBC_2.31 strtof32 F
+GLIBC_2.31 strtof32_l F
+GLIBC_2.31 strtof32x F
+GLIBC_2.31 strtof32x_l F
+GLIBC_2.31 strtof64 F
+GLIBC_2.31 strtof64_l F
+GLIBC_2.31 strtof64x F
+GLIBC_2.31 strtof64x_l F
+GLIBC_2.31 strtof_l F
+GLIBC_2.31 strtoimax F
+GLIBC_2.31 strtok F
+GLIBC_2.31 strtok_r F
+GLIBC_2.31 strtol F
+GLIBC_2.31 strtol_l F
+GLIBC_2.31 strtold F
+GLIBC_2.31 strtold_l F
+GLIBC_2.31 strtoll F
+GLIBC_2.31 strtoll_l F
+GLIBC_2.31 strtoq F
+GLIBC_2.31 strtoul F
+GLIBC_2.31 strtoul_l F
+GLIBC_2.31 strtoull F
+GLIBC_2.31 strtoull_l F
+GLIBC_2.31 strtoumax F
+GLIBC_2.31 strtouq F
+GLIBC_2.31 strverscmp F
+GLIBC_2.31 strxfrm F
+GLIBC_2.31 strxfrm_l F
+GLIBC_2.31 stty F
+GLIBC_2.31 svc_exit F
+GLIBC_2.31 svc_fdset D 0x80
+GLIBC_2.31 svc_getreq F
+GLIBC_2.31 svc_getreq_common F
+GLIBC_2.31 svc_getreq_poll F
+GLIBC_2.31 svc_getreqset F
+GLIBC_2.31 svc_max_pollfd D 0x4
+GLIBC_2.31 svc_pollfd D 0x4
+GLIBC_2.31 svc_register F
+GLIBC_2.31 svc_run F
+GLIBC_2.31 svc_sendreply F
+GLIBC_2.31 svc_unregister F
+GLIBC_2.31 svcauthdes_stats D 0xc
+GLIBC_2.31 svcerr_auth F
+GLIBC_2.31 svcerr_decode F
+GLIBC_2.31 svcerr_noproc F
+GLIBC_2.31 svcerr_noprog F
+GLIBC_2.31 svcerr_progvers F
+GLIBC_2.31 svcerr_systemerr F
+GLIBC_2.31 svcerr_weakauth F
+GLIBC_2.31 svcfd_create F
+GLIBC_2.31 svcraw_create F
+GLIBC_2.31 svctcp_create F
+GLIBC_2.31 svcudp_bufcreate F
+GLIBC_2.31 svcudp_create F
+GLIBC_2.31 svcudp_enablecache F
+GLIBC_2.31 svcunix_create F
+GLIBC_2.31 svcunixfd_create F
+GLIBC_2.31 swab F
+GLIBC_2.31 swapcontext F
+GLIBC_2.31 swapoff F
+GLIBC_2.31 swapon F
+GLIBC_2.31 swprintf F
+GLIBC_2.31 swscanf F
+GLIBC_2.31 symlink F
+GLIBC_2.31 symlinkat F
+GLIBC_2.31 sync F
+GLIBC_2.31 sync_file_range F
+GLIBC_2.31 syncfs F
+GLIBC_2.31 sys_errlist D 0x21c
+GLIBC_2.31 sys_nerr D 0x4
+GLIBC_2.31 sys_sigabbrev D 0x104
+GLIBC_2.31 sys_siglist D 0x104
+GLIBC_2.31 syscall F
+GLIBC_2.31 sysconf F
+GLIBC_2.31 sysctl F
+GLIBC_2.31 sysinfo F
+GLIBC_2.31 syslog F
+GLIBC_2.31 system F
+GLIBC_2.31 sysv_signal F
+GLIBC_2.31 tcdrain F
+GLIBC_2.31 tcflow F
+GLIBC_2.31 tcflush F
+GLIBC_2.31 tcgetattr F
+GLIBC_2.31 tcgetpgrp F
+GLIBC_2.31 tcgetsid F
+GLIBC_2.31 tcsendbreak F
+GLIBC_2.31 tcsetattr F
+GLIBC_2.31 tcsetpgrp F
+GLIBC_2.31 tdelete F
+GLIBC_2.31 tdestroy F
+GLIBC_2.31 tee F
+GLIBC_2.31 telldir F
+GLIBC_2.31 tempnam F
+GLIBC_2.31 textdomain F
+GLIBC_2.31 tfind F
+GLIBC_2.31 tgkill F
+GLIBC_2.31 thrd_current F
+GLIBC_2.31 thrd_equal F
+GLIBC_2.31 thrd_sleep F
+GLIBC_2.31 thrd_yield F
+GLIBC_2.31 time F
+GLIBC_2.31 timegm F
+GLIBC_2.31 timelocal F
+GLIBC_2.31 timerfd_create F
+GLIBC_2.31 timerfd_gettime F
+GLIBC_2.31 timerfd_settime F
+GLIBC_2.31 times F
+GLIBC_2.31 timespec_get F
+GLIBC_2.31 timezone D 0x4
+GLIBC_2.31 tmpfile F
+GLIBC_2.31 tmpfile64 F
+GLIBC_2.31 tmpnam F
+GLIBC_2.31 tmpnam_r F
+GLIBC_2.31 toascii F
+GLIBC_2.31 tolower F
+GLIBC_2.31 tolower_l F
+GLIBC_2.31 toupper F
+GLIBC_2.31 toupper_l F
+GLIBC_2.31 towctrans F
+GLIBC_2.31 towctrans_l F
+GLIBC_2.31 towlower F
+GLIBC_2.31 towlower_l F
+GLIBC_2.31 towupper F
+GLIBC_2.31 towupper_l F
+GLIBC_2.31 tr_break F
+GLIBC_2.31 truncate F
+GLIBC_2.31 truncate64 F
+GLIBC_2.31 tsearch F
+GLIBC_2.31 ttyname F
+GLIBC_2.31 ttyname_r F
+GLIBC_2.31 ttyslot F
+GLIBC_2.31 twalk F
+GLIBC_2.31 twalk_r F
+GLIBC_2.31 tzname D 0x8
+GLIBC_2.31 tzset F
+GLIBC_2.31 ualarm F
+GLIBC_2.31 ulckpwdf F
+GLIBC_2.31 ulimit F
+GLIBC_2.31 umask F
+GLIBC_2.31 umount F
+GLIBC_2.31 umount2 F
+GLIBC_2.31 uname F
+GLIBC_2.31 ungetc F
+GLIBC_2.31 ungetwc F
+GLIBC_2.31 unlink F
+GLIBC_2.31 unlinkat F
+GLIBC_2.31 unlockpt F
+GLIBC_2.31 unsetenv F
+GLIBC_2.31 unshare F
+GLIBC_2.31 updwtmp F
+GLIBC_2.31 updwtmpx F
+GLIBC_2.31 uselocale F
+GLIBC_2.31 user2netname F
+GLIBC_2.31 usleep F
+GLIBC_2.31 utime F
+GLIBC_2.31 utimensat F
+GLIBC_2.31 utimes F
+GLIBC_2.31 utmpname F
+GLIBC_2.31 utmpxname F
+GLIBC_2.31 valloc F
+GLIBC_2.31 vasprintf F
+GLIBC_2.31 vdprintf F
+GLIBC_2.31 verr F
+GLIBC_2.31 verrx F
+GLIBC_2.31 versionsort F
+GLIBC_2.31 versionsort64 F
+GLIBC_2.31 vfork F
+GLIBC_2.31 vfprintf F
+GLIBC_2.31 vfscanf F
+GLIBC_2.31 vfwprintf F
+GLIBC_2.31 vfwscanf F
+GLIBC_2.31 vhangup F
+GLIBC_2.31 vlimit F
+GLIBC_2.31 vmsplice F
+GLIBC_2.31 vprintf F
+GLIBC_2.31 vscanf F
+GLIBC_2.31 vsnprintf F
+GLIBC_2.31 vsprintf F
+GLIBC_2.31 vsscanf F
+GLIBC_2.31 vswprintf F
+GLIBC_2.31 vswscanf F
+GLIBC_2.31 vsyslog F
+GLIBC_2.31 vtimes F
+GLIBC_2.31 vwarn F
+GLIBC_2.31 vwarnx F
+GLIBC_2.31 vwprintf F
+GLIBC_2.31 vwscanf F
+GLIBC_2.31 wait F
+GLIBC_2.31 wait3 F
+GLIBC_2.31 wait4 F
+GLIBC_2.31 waitid F
+GLIBC_2.31 waitpid F
+GLIBC_2.31 warn F
+GLIBC_2.31 warnx F
+GLIBC_2.31 wcpcpy F
+GLIBC_2.31 wcpncpy F
+GLIBC_2.31 wcrtomb F
+GLIBC_2.31 wcscasecmp F
+GLIBC_2.31 wcscasecmp_l F
+GLIBC_2.31 wcscat F
+GLIBC_2.31 wcschr F
+GLIBC_2.31 wcschrnul F
+GLIBC_2.31 wcscmp F
+GLIBC_2.31 wcscoll F
+GLIBC_2.31 wcscoll_l F
+GLIBC_2.31 wcscpy F
+GLIBC_2.31 wcscspn F
+GLIBC_2.31 wcsdup F
+GLIBC_2.31 wcsftime F
+GLIBC_2.31 wcsftime_l F
+GLIBC_2.31 wcslen F
+GLIBC_2.31 wcsncasecmp F
+GLIBC_2.31 wcsncasecmp_l F
+GLIBC_2.31 wcsncat F
+GLIBC_2.31 wcsncmp F
+GLIBC_2.31 wcsncpy F
+GLIBC_2.31 wcsnlen F
+GLIBC_2.31 wcsnrtombs F
+GLIBC_2.31 wcspbrk F
+GLIBC_2.31 wcsrchr F
+GLIBC_2.31 wcsrtombs F
+GLIBC_2.31 wcsspn F
+GLIBC_2.31 wcsstr F
+GLIBC_2.31 wcstod F
+GLIBC_2.31 wcstod_l F
+GLIBC_2.31 wcstof F
+GLIBC_2.31 wcstof128 F
+GLIBC_2.31 wcstof128_l F
+GLIBC_2.31 wcstof32 F
+GLIBC_2.31 wcstof32_l F
+GLIBC_2.31 wcstof32x F
+GLIBC_2.31 wcstof32x_l F
+GLIBC_2.31 wcstof64 F
+GLIBC_2.31 wcstof64_l F
+GLIBC_2.31 wcstof64x F
+GLIBC_2.31 wcstof64x_l F
+GLIBC_2.31 wcstof_l F
+GLIBC_2.31 wcstoimax F
+GLIBC_2.31 wcstok F
+GLIBC_2.31 wcstol F
+GLIBC_2.31 wcstol_l F
+GLIBC_2.31 wcstold F
+GLIBC_2.31 wcstold_l F
+GLIBC_2.31 wcstoll F
+GLIBC_2.31 wcstoll_l F
+GLIBC_2.31 wcstombs F
+GLIBC_2.31 wcstoq F
+GLIBC_2.31 wcstoul F
+GLIBC_2.31 wcstoul_l F
+GLIBC_2.31 wcstoull F
+GLIBC_2.31 wcstoull_l F
+GLIBC_2.31 wcstoumax F
+GLIBC_2.31 wcstouq F
+GLIBC_2.31 wcswcs F
+GLIBC_2.31 wcswidth F
+GLIBC_2.31 wcsxfrm F
+GLIBC_2.31 wcsxfrm_l F
+GLIBC_2.31 wctob F
+GLIBC_2.31 wctomb F
+GLIBC_2.31 wctrans F
+GLIBC_2.31 wctrans_l F
+GLIBC_2.31 wctype F
+GLIBC_2.31 wctype_l F
+GLIBC_2.31 wcwidth F
+GLIBC_2.31 wmemchr F
+GLIBC_2.31 wmemcmp F
+GLIBC_2.31 wmemcpy F
+GLIBC_2.31 wmemmove F
+GLIBC_2.31 wmempcpy F
+GLIBC_2.31 wmemset F
+GLIBC_2.31 wordexp F
+GLIBC_2.31 wordfree F
+GLIBC_2.31 wprintf F
+GLIBC_2.31 write F
+GLIBC_2.31 writev F
+GLIBC_2.31 wscanf F
+GLIBC_2.31 xdecrypt F
+GLIBC_2.31 xdr_accepted_reply F
+GLIBC_2.31 xdr_array F
+GLIBC_2.31 xdr_authdes_cred F
+GLIBC_2.31 xdr_authdes_verf F
+GLIBC_2.31 xdr_authunix_parms F
+GLIBC_2.31 xdr_bool F
+GLIBC_2.31 xdr_bytes F
+GLIBC_2.31 xdr_callhdr F
+GLIBC_2.31 xdr_callmsg F
+GLIBC_2.31 xdr_char F
+GLIBC_2.31 xdr_cryptkeyarg F
+GLIBC_2.31 xdr_cryptkeyarg2 F
+GLIBC_2.31 xdr_cryptkeyres F
+GLIBC_2.31 xdr_des_block F
+GLIBC_2.31 xdr_double F
+GLIBC_2.31 xdr_enum F
+GLIBC_2.31 xdr_float F
+GLIBC_2.31 xdr_free F
+GLIBC_2.31 xdr_getcredres F
+GLIBC_2.31 xdr_hyper F
+GLIBC_2.31 xdr_int F
+GLIBC_2.31 xdr_int16_t F
+GLIBC_2.31 xdr_int32_t F
+GLIBC_2.31 xdr_int64_t F
+GLIBC_2.31 xdr_int8_t F
+GLIBC_2.31 xdr_key_netstarg F
+GLIBC_2.31 xdr_key_netstres F
+GLIBC_2.31 xdr_keybuf F
+GLIBC_2.31 xdr_keystatus F
+GLIBC_2.31 xdr_long F
+GLIBC_2.31 xdr_longlong_t F
+GLIBC_2.31 xdr_netnamestr F
+GLIBC_2.31 xdr_netobj F
+GLIBC_2.31 xdr_opaque F
+GLIBC_2.31 xdr_opaque_auth F
+GLIBC_2.31 xdr_pmap F
+GLIBC_2.31 xdr_pmaplist F
+GLIBC_2.31 xdr_pointer F
+GLIBC_2.31 xdr_quad_t F
+GLIBC_2.31 xdr_reference F
+GLIBC_2.31 xdr_rejected_reply F
+GLIBC_2.31 xdr_replymsg F
+GLIBC_2.31 xdr_rmtcall_args F
+GLIBC_2.31 xdr_rmtcallres F
+GLIBC_2.31 xdr_short F
+GLIBC_2.31 xdr_sizeof F
+GLIBC_2.31 xdr_string F
+GLIBC_2.31 xdr_u_char F
+GLIBC_2.31 xdr_u_hyper F
+GLIBC_2.31 xdr_u_int F
+GLIBC_2.31 xdr_u_long F
+GLIBC_2.31 xdr_u_longlong_t F
+GLIBC_2.31 xdr_u_quad_t F
+GLIBC_2.31 xdr_u_short F
+GLIBC_2.31 xdr_uint16_t F
+GLIBC_2.31 xdr_uint32_t F
+GLIBC_2.31 xdr_uint64_t F
+GLIBC_2.31 xdr_uint8_t F
+GLIBC_2.31 xdr_union F
+GLIBC_2.31 xdr_unixcred F
+GLIBC_2.31 xdr_vector F
+GLIBC_2.31 xdr_void F
+GLIBC_2.31 xdr_wrapstring F
+GLIBC_2.31 xdrmem_create F
+GLIBC_2.31 xdrrec_create F
+GLIBC_2.31 xdrrec_endofrecord F
+GLIBC_2.31 xdrrec_eof F
+GLIBC_2.31 xdrrec_skiprecord F
+GLIBC_2.31 xdrstdio_create F
+GLIBC_2.31 xencrypt F
+GLIBC_2.31 xprt_register F
+GLIBC_2.31 xprt_unregister F
diff --git a/sysdeps/unix/sysv/linux/riscv/libcrypt.abilist b/sysdeps/unix/sysv/linux/riscv/libcrypt.abilist
new file mode 100644
index 0000000000..9454aa7f33
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/libcrypt.abilist
@@ -0,0 +1,2 @@
+GLIBC_2.31 crypt F
+GLIBC_2.31 crypt_r F
diff --git a/sysdeps/unix/sysv/linux/riscv/libdl.abilist b/sysdeps/unix/sysv/linux/riscv/libdl.abilist
new file mode 100644
index 0000000000..b540344430
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/libdl.abilist
@@ -0,0 +1,9 @@
+GLIBC_2.31 dladdr F
+GLIBC_2.31 dladdr1 F
+GLIBC_2.31 dlclose F
+GLIBC_2.31 dlerror F
+GLIBC_2.31 dlinfo F
+GLIBC_2.31 dlmopen F
+GLIBC_2.31 dlopen F
+GLIBC_2.31 dlsym F
+GLIBC_2.31 dlvsym F
diff --git a/sysdeps/unix/sysv/linux/riscv/libm.abilist b/sysdeps/unix/sysv/linux/riscv/libm.abilist
new file mode 100644
index 0000000000..1ba07b36dc
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/libm.abilist
@@ -0,0 +1,940 @@
+GLIBC_2.31 __clog10 F
+GLIBC_2.31 __clog10f F
+GLIBC_2.31 __clog10l F
+GLIBC_2.31 __finite F
+GLIBC_2.31 __finitef F
+GLIBC_2.31 __finitel F
+GLIBC_2.31 __fpclassify F
+GLIBC_2.31 __fpclassifyf F
+GLIBC_2.31 __fpclassifyl F
+GLIBC_2.31 __iseqsig F
+GLIBC_2.31 __iseqsigf F
+GLIBC_2.31 __iseqsigl F
+GLIBC_2.31 __issignaling F
+GLIBC_2.31 __issignalingf F
+GLIBC_2.31 __issignalingl F
+GLIBC_2.31 __signbit F
+GLIBC_2.31 __signbitf F
+GLIBC_2.31 __signbitl F
+GLIBC_2.31 __signgam D 0x4
+GLIBC_2.31 acos F
+GLIBC_2.31 acosf F
+GLIBC_2.31 acosf128 F
+GLIBC_2.31 acosf32 F
+GLIBC_2.31 acosf32x F
+GLIBC_2.31 acosf64 F
+GLIBC_2.31 acosf64x F
+GLIBC_2.31 acosh F
+GLIBC_2.31 acoshf F
+GLIBC_2.31 acoshf128 F
+GLIBC_2.31 acoshf32 F
+GLIBC_2.31 acoshf32x F
+GLIBC_2.31 acoshf64 F
+GLIBC_2.31 acoshf64x F
+GLIBC_2.31 acoshl F
+GLIBC_2.31 acosl F
+GLIBC_2.31 asin F
+GLIBC_2.31 asinf F
+GLIBC_2.31 asinf128 F
+GLIBC_2.31 asinf32 F
+GLIBC_2.31 asinf32x F
+GLIBC_2.31 asinf64 F
+GLIBC_2.31 asinf64x F
+GLIBC_2.31 asinh F
+GLIBC_2.31 asinhf F
+GLIBC_2.31 asinhf128 F
+GLIBC_2.31 asinhf32 F
+GLIBC_2.31 asinhf32x F
+GLIBC_2.31 asinhf64 F
+GLIBC_2.31 asinhf64x F
+GLIBC_2.31 asinhl F
+GLIBC_2.31 asinl F
+GLIBC_2.31 atan F
+GLIBC_2.31 atan2 F
+GLIBC_2.31 atan2f F
+GLIBC_2.31 atan2f128 F
+GLIBC_2.31 atan2f32 F
+GLIBC_2.31 atan2f32x F
+GLIBC_2.31 atan2f64 F
+GLIBC_2.31 atan2f64x F
+GLIBC_2.31 atan2l F
+GLIBC_2.31 atanf F
+GLIBC_2.31 atanf128 F
+GLIBC_2.31 atanf32 F
+GLIBC_2.31 atanf32x F
+GLIBC_2.31 atanf64 F
+GLIBC_2.31 atanf64x F
+GLIBC_2.31 atanh F
+GLIBC_2.31 atanhf F
+GLIBC_2.31 atanhf128 F
+GLIBC_2.31 atanhf32 F
+GLIBC_2.31 atanhf32x F
+GLIBC_2.31 atanhf64 F
+GLIBC_2.31 atanhf64x F
+GLIBC_2.31 atanhl F
+GLIBC_2.31 atanl F
+GLIBC_2.31 cabs F
+GLIBC_2.31 cabsf F
+GLIBC_2.31 cabsf128 F
+GLIBC_2.31 cabsf32 F
+GLIBC_2.31 cabsf32x F
+GLIBC_2.31 cabsf64 F
+GLIBC_2.31 cabsf64x F
+GLIBC_2.31 cabsl F
+GLIBC_2.31 cacos F
+GLIBC_2.31 cacosf F
+GLIBC_2.31 cacosf128 F
+GLIBC_2.31 cacosf32 F
+GLIBC_2.31 cacosf32x F
+GLIBC_2.31 cacosf64 F
+GLIBC_2.31 cacosf64x F
+GLIBC_2.31 cacosh F
+GLIBC_2.31 cacoshf F
+GLIBC_2.31 cacoshf128 F
+GLIBC_2.31 cacoshf32 F
+GLIBC_2.31 cacoshf32x F
+GLIBC_2.31 cacoshf64 F
+GLIBC_2.31 cacoshf64x F
+GLIBC_2.31 cacoshl F
+GLIBC_2.31 cacosl F
+GLIBC_2.31 canonicalize F
+GLIBC_2.31 canonicalizef F
+GLIBC_2.31 canonicalizef128 F
+GLIBC_2.31 canonicalizef32 F
+GLIBC_2.31 canonicalizef32x F
+GLIBC_2.31 canonicalizef64 F
+GLIBC_2.31 canonicalizef64x F
+GLIBC_2.31 canonicalizel F
+GLIBC_2.31 carg F
+GLIBC_2.31 cargf F
+GLIBC_2.31 cargf128 F
+GLIBC_2.31 cargf32 F
+GLIBC_2.31 cargf32x F
+GLIBC_2.31 cargf64 F
+GLIBC_2.31 cargf64x F
+GLIBC_2.31 cargl F
+GLIBC_2.31 casin F
+GLIBC_2.31 casinf F
+GLIBC_2.31 casinf128 F
+GLIBC_2.31 casinf32 F
+GLIBC_2.31 casinf32x F
+GLIBC_2.31 casinf64 F
+GLIBC_2.31 casinf64x F
+GLIBC_2.31 casinh F
+GLIBC_2.31 casinhf F
+GLIBC_2.31 casinhf128 F
+GLIBC_2.31 casinhf32 F
+GLIBC_2.31 casinhf32x F
+GLIBC_2.31 casinhf64 F
+GLIBC_2.31 casinhf64x F
+GLIBC_2.31 casinhl F
+GLIBC_2.31 casinl F
+GLIBC_2.31 catan F
+GLIBC_2.31 catanf F
+GLIBC_2.31 catanf128 F
+GLIBC_2.31 catanf32 F
+GLIBC_2.31 catanf32x F
+GLIBC_2.31 catanf64 F
+GLIBC_2.31 catanf64x F
+GLIBC_2.31 catanh F
+GLIBC_2.31 catanhf F
+GLIBC_2.31 catanhf128 F
+GLIBC_2.31 catanhf32 F
+GLIBC_2.31 catanhf32x F
+GLIBC_2.31 catanhf64 F
+GLIBC_2.31 catanhf64x F
+GLIBC_2.31 catanhl F
+GLIBC_2.31 catanl F
+GLIBC_2.31 cbrt F
+GLIBC_2.31 cbrtf F
+GLIBC_2.31 cbrtf128 F
+GLIBC_2.31 cbrtf32 F
+GLIBC_2.31 cbrtf32x F
+GLIBC_2.31 cbrtf64 F
+GLIBC_2.31 cbrtf64x F
+GLIBC_2.31 cbrtl F
+GLIBC_2.31 ccos F
+GLIBC_2.31 ccosf F
+GLIBC_2.31 ccosf128 F
+GLIBC_2.31 ccosf32 F
+GLIBC_2.31 ccosf32x F
+GLIBC_2.31 ccosf64 F
+GLIBC_2.31 ccosf64x F
+GLIBC_2.31 ccosh F
+GLIBC_2.31 ccoshf F
+GLIBC_2.31 ccoshf128 F
+GLIBC_2.31 ccoshf32 F
+GLIBC_2.31 ccoshf32x F
+GLIBC_2.31 ccoshf64 F
+GLIBC_2.31 ccoshf64x F
+GLIBC_2.31 ccoshl F
+GLIBC_2.31 ccosl F
+GLIBC_2.31 ceil F
+GLIBC_2.31 ceilf F
+GLIBC_2.31 ceilf128 F
+GLIBC_2.31 ceilf32 F
+GLIBC_2.31 ceilf32x F
+GLIBC_2.31 ceilf64 F
+GLIBC_2.31 ceilf64x F
+GLIBC_2.31 ceill F
+GLIBC_2.31 cexp F
+GLIBC_2.31 cexpf F
+GLIBC_2.31 cexpf128 F
+GLIBC_2.31 cexpf32 F
+GLIBC_2.31 cexpf32x F
+GLIBC_2.31 cexpf64 F
+GLIBC_2.31 cexpf64x F
+GLIBC_2.31 cexpl F
+GLIBC_2.31 cimag F
+GLIBC_2.31 cimagf F
+GLIBC_2.31 cimagf128 F
+GLIBC_2.31 cimagf32 F
+GLIBC_2.31 cimagf32x F
+GLIBC_2.31 cimagf64 F
+GLIBC_2.31 cimagf64x F
+GLIBC_2.31 cimagl F
+GLIBC_2.31 clog F
+GLIBC_2.31 clog10 F
+GLIBC_2.31 clog10f F
+GLIBC_2.31 clog10f128 F
+GLIBC_2.31 clog10f32 F
+GLIBC_2.31 clog10f32x F
+GLIBC_2.31 clog10f64 F
+GLIBC_2.31 clog10f64x F
+GLIBC_2.31 clog10l F
+GLIBC_2.31 clogf F
+GLIBC_2.31 clogf128 F
+GLIBC_2.31 clogf32 F
+GLIBC_2.31 clogf32x F
+GLIBC_2.31 clogf64 F
+GLIBC_2.31 clogf64x F
+GLIBC_2.31 clogl F
+GLIBC_2.31 conj F
+GLIBC_2.31 conjf F
+GLIBC_2.31 conjf128 F
+GLIBC_2.31 conjf32 F
+GLIBC_2.31 conjf32x F
+GLIBC_2.31 conjf64 F
+GLIBC_2.31 conjf64x F
+GLIBC_2.31 conjl F
+GLIBC_2.31 copysign F
+GLIBC_2.31 copysignf F
+GLIBC_2.31 copysignf128 F
+GLIBC_2.31 copysignf32 F
+GLIBC_2.31 copysignf32x F
+GLIBC_2.31 copysignf64 F
+GLIBC_2.31 copysignf64x F
+GLIBC_2.31 copysignl F
+GLIBC_2.31 cos F
+GLIBC_2.31 cosf F
+GLIBC_2.31 cosf128 F
+GLIBC_2.31 cosf32 F
+GLIBC_2.31 cosf32x F
+GLIBC_2.31 cosf64 F
+GLIBC_2.31 cosf64x F
+GLIBC_2.31 cosh F
+GLIBC_2.31 coshf F
+GLIBC_2.31 coshf128 F
+GLIBC_2.31 coshf32 F
+GLIBC_2.31 coshf32x F
+GLIBC_2.31 coshf64 F
+GLIBC_2.31 coshf64x F
+GLIBC_2.31 coshl F
+GLIBC_2.31 cosl F
+GLIBC_2.31 cpow F
+GLIBC_2.31 cpowf F
+GLIBC_2.31 cpowf128 F
+GLIBC_2.31 cpowf32 F
+GLIBC_2.31 cpowf32x F
+GLIBC_2.31 cpowf64 F
+GLIBC_2.31 cpowf64x F
+GLIBC_2.31 cpowl F
+GLIBC_2.31 cproj F
+GLIBC_2.31 cprojf F
+GLIBC_2.31 cprojf128 F
+GLIBC_2.31 cprojf32 F
+GLIBC_2.31 cprojf32x F
+GLIBC_2.31 cprojf64 F
+GLIBC_2.31 cprojf64x F
+GLIBC_2.31 cprojl F
+GLIBC_2.31 creal F
+GLIBC_2.31 crealf F
+GLIBC_2.31 crealf128 F
+GLIBC_2.31 crealf32 F
+GLIBC_2.31 crealf32x F
+GLIBC_2.31 crealf64 F
+GLIBC_2.31 crealf64x F
+GLIBC_2.31 creall F
+GLIBC_2.31 csin F
+GLIBC_2.31 csinf F
+GLIBC_2.31 csinf128 F
+GLIBC_2.31 csinf32 F
+GLIBC_2.31 csinf32x F
+GLIBC_2.31 csinf64 F
+GLIBC_2.31 csinf64x F
+GLIBC_2.31 csinh F
+GLIBC_2.31 csinhf F
+GLIBC_2.31 csinhf128 F
+GLIBC_2.31 csinhf32 F
+GLIBC_2.31 csinhf32x F
+GLIBC_2.31 csinhf64 F
+GLIBC_2.31 csinhf64x F
+GLIBC_2.31 csinhl F
+GLIBC_2.31 csinl F
+GLIBC_2.31 csqrt F
+GLIBC_2.31 csqrtf F
+GLIBC_2.31 csqrtf128 F
+GLIBC_2.31 csqrtf32 F
+GLIBC_2.31 csqrtf32x F
+GLIBC_2.31 csqrtf64 F
+GLIBC_2.31 csqrtf64x F
+GLIBC_2.31 csqrtl F
+GLIBC_2.31 ctan F
+GLIBC_2.31 ctanf F
+GLIBC_2.31 ctanf128 F
+GLIBC_2.31 ctanf32 F
+GLIBC_2.31 ctanf32x F
+GLIBC_2.31 ctanf64 F
+GLIBC_2.31 ctanf64x F
+GLIBC_2.31 ctanh F
+GLIBC_2.31 ctanhf F
+GLIBC_2.31 ctanhf128 F
+GLIBC_2.31 ctanhf32 F
+GLIBC_2.31 ctanhf32x F
+GLIBC_2.31 ctanhf64 F
+GLIBC_2.31 ctanhf64x F
+GLIBC_2.31 ctanhl F
+GLIBC_2.31 ctanl F
+GLIBC_2.31 daddl F
+GLIBC_2.31 ddivl F
+GLIBC_2.31 dmull F
+GLIBC_2.31 drem F
+GLIBC_2.31 dremf F
+GLIBC_2.31 dreml F
+GLIBC_2.31 dsubl F
+GLIBC_2.31 erf F
+GLIBC_2.31 erfc F
+GLIBC_2.31 erfcf F
+GLIBC_2.31 erfcf128 F
+GLIBC_2.31 erfcf32 F
+GLIBC_2.31 erfcf32x F
+GLIBC_2.31 erfcf64 F
+GLIBC_2.31 erfcf64x F
+GLIBC_2.31 erfcl F
+GLIBC_2.31 erff F
+GLIBC_2.31 erff128 F
+GLIBC_2.31 erff32 F
+GLIBC_2.31 erff32x F
+GLIBC_2.31 erff64 F
+GLIBC_2.31 erff64x F
+GLIBC_2.31 erfl F
+GLIBC_2.31 exp F
+GLIBC_2.31 exp10 F
+GLIBC_2.31 exp10f F
+GLIBC_2.31 exp10f128 F
+GLIBC_2.31 exp10f32 F
+GLIBC_2.31 exp10f32x F
+GLIBC_2.31 exp10f64 F
+GLIBC_2.31 exp10f64x F
+GLIBC_2.31 exp10l F
+GLIBC_2.31 exp2 F
+GLIBC_2.31 exp2f F
+GLIBC_2.31 exp2f128 F
+GLIBC_2.31 exp2f32 F
+GLIBC_2.31 exp2f32x F
+GLIBC_2.31 exp2f64 F
+GLIBC_2.31 exp2f64x F
+GLIBC_2.31 exp2l F
+GLIBC_2.31 expf F
+GLIBC_2.31 expf128 F
+GLIBC_2.31 expf32 F
+GLIBC_2.31 expf32x F
+GLIBC_2.31 expf64 F
+GLIBC_2.31 expf64x F
+GLIBC_2.31 expl F
+GLIBC_2.31 expm1 F
+GLIBC_2.31 expm1f F
+GLIBC_2.31 expm1f128 F
+GLIBC_2.31 expm1f32 F
+GLIBC_2.31 expm1f32x F
+GLIBC_2.31 expm1f64 F
+GLIBC_2.31 expm1f64x F
+GLIBC_2.31 expm1l F
+GLIBC_2.31 f32addf128 F
+GLIBC_2.31 f32addf32x F
+GLIBC_2.31 f32addf64 F
+GLIBC_2.31 f32addf64x F
+GLIBC_2.31 f32divf128 F
+GLIBC_2.31 f32divf32x F
+GLIBC_2.31 f32divf64 F
+GLIBC_2.31 f32divf64x F
+GLIBC_2.31 f32mulf128 F
+GLIBC_2.31 f32mulf32x F
+GLIBC_2.31 f32mulf64 F
+GLIBC_2.31 f32mulf64x F
+GLIBC_2.31 f32subf128 F
+GLIBC_2.31 f32subf32x F
+GLIBC_2.31 f32subf64 F
+GLIBC_2.31 f32subf64x F
+GLIBC_2.31 f32xaddf128 F
+GLIBC_2.31 f32xaddf64 F
+GLIBC_2.31 f32xaddf64x F
+GLIBC_2.31 f32xdivf128 F
+GLIBC_2.31 f32xdivf64 F
+GLIBC_2.31 f32xdivf64x F
+GLIBC_2.31 f32xmulf128 F
+GLIBC_2.31 f32xmulf64 F
+GLIBC_2.31 f32xmulf64x F
+GLIBC_2.31 f32xsubf128 F
+GLIBC_2.31 f32xsubf64 F
+GLIBC_2.31 f32xsubf64x F
+GLIBC_2.31 f64addf128 F
+GLIBC_2.31 f64addf64x F
+GLIBC_2.31 f64divf128 F
+GLIBC_2.31 f64divf64x F
+GLIBC_2.31 f64mulf128 F
+GLIBC_2.31 f64mulf64x F
+GLIBC_2.31 f64subf128 F
+GLIBC_2.31 f64subf64x F
+GLIBC_2.31 f64xaddf128 F
+GLIBC_2.31 f64xdivf128 F
+GLIBC_2.31 f64xmulf128 F
+GLIBC_2.31 f64xsubf128 F
+GLIBC_2.31 fabs F
+GLIBC_2.31 fabsf F
+GLIBC_2.31 fabsf128 F
+GLIBC_2.31 fabsf32 F
+GLIBC_2.31 fabsf32x F
+GLIBC_2.31 fabsf64 F
+GLIBC_2.31 fabsf64x F
+GLIBC_2.31 fabsl F
+GLIBC_2.31 fadd F
+GLIBC_2.31 faddl F
+GLIBC_2.31 fdim F
+GLIBC_2.31 fdimf F
+GLIBC_2.31 fdimf128 F
+GLIBC_2.31 fdimf32 F
+GLIBC_2.31 fdimf32x F
+GLIBC_2.31 fdimf64 F
+GLIBC_2.31 fdimf64x F
+GLIBC_2.31 fdiml F
+GLIBC_2.31 fdiv F
+GLIBC_2.31 fdivl F
+GLIBC_2.31 feclearexcept F
+GLIBC_2.31 fedisableexcept F
+GLIBC_2.31 feenableexcept F
+GLIBC_2.31 fegetenv F
+GLIBC_2.31 fegetexcept F
+GLIBC_2.31 fegetexceptflag F
+GLIBC_2.31 fegetmode F
+GLIBC_2.31 fegetround F
+GLIBC_2.31 feholdexcept F
+GLIBC_2.31 feraiseexcept F
+GLIBC_2.31 fesetenv F
+GLIBC_2.31 fesetexcept F
+GLIBC_2.31 fesetexceptflag F
+GLIBC_2.31 fesetmode F
+GLIBC_2.31 fesetround F
+GLIBC_2.31 fetestexcept F
+GLIBC_2.31 fetestexceptflag F
+GLIBC_2.31 feupdateenv F
+GLIBC_2.31 finite F
+GLIBC_2.31 finitef F
+GLIBC_2.31 finitel F
+GLIBC_2.31 floor F
+GLIBC_2.31 floorf F
+GLIBC_2.31 floorf128 F
+GLIBC_2.31 floorf32 F
+GLIBC_2.31 floorf32x F
+GLIBC_2.31 floorf64 F
+GLIBC_2.31 floorf64x F
+GLIBC_2.31 floorl F
+GLIBC_2.31 fma F
+GLIBC_2.31 fmaf F
+GLIBC_2.31 fmaf128 F
+GLIBC_2.31 fmaf32 F
+GLIBC_2.31 fmaf32x F
+GLIBC_2.31 fmaf64 F
+GLIBC_2.31 fmaf64x F
+GLIBC_2.31 fmal F
+GLIBC_2.31 fmax F
+GLIBC_2.31 fmaxf F
+GLIBC_2.31 fmaxf128 F
+GLIBC_2.31 fmaxf32 F
+GLIBC_2.31 fmaxf32x F
+GLIBC_2.31 fmaxf64 F
+GLIBC_2.31 fmaxf64x F
+GLIBC_2.31 fmaxl F
+GLIBC_2.31 fmaxmag F
+GLIBC_2.31 fmaxmagf F
+GLIBC_2.31 fmaxmagf128 F
+GLIBC_2.31 fmaxmagf32 F
+GLIBC_2.31 fmaxmagf32x F
+GLIBC_2.31 fmaxmagf64 F
+GLIBC_2.31 fmaxmagf64x F
+GLIBC_2.31 fmaxmagl F
+GLIBC_2.31 fmin F
+GLIBC_2.31 fminf F
+GLIBC_2.31 fminf128 F
+GLIBC_2.31 fminf32 F
+GLIBC_2.31 fminf32x F
+GLIBC_2.31 fminf64 F
+GLIBC_2.31 fminf64x F
+GLIBC_2.31 fminl F
+GLIBC_2.31 fminmag F
+GLIBC_2.31 fminmagf F
+GLIBC_2.31 fminmagf128 F
+GLIBC_2.31 fminmagf32 F
+GLIBC_2.31 fminmagf32x F
+GLIBC_2.31 fminmagf64 F
+GLIBC_2.31 fminmagf64x F
+GLIBC_2.31 fminmagl F
+GLIBC_2.31 fmod F
+GLIBC_2.31 fmodf F
+GLIBC_2.31 fmodf128 F
+GLIBC_2.31 fmodf32 F
+GLIBC_2.31 fmodf32x F
+GLIBC_2.31 fmodf64 F
+GLIBC_2.31 fmodf64x F
+GLIBC_2.31 fmodl F
+GLIBC_2.31 fmul F
+GLIBC_2.31 fmull F
+GLIBC_2.31 frexp F
+GLIBC_2.31 frexpf F
+GLIBC_2.31 frexpf128 F
+GLIBC_2.31 frexpf32 F
+GLIBC_2.31 frexpf32x F
+GLIBC_2.31 frexpf64 F
+GLIBC_2.31 frexpf64x F
+GLIBC_2.31 frexpl F
+GLIBC_2.31 fromfp F
+GLIBC_2.31 fromfpf F
+GLIBC_2.31 fromfpf128 F
+GLIBC_2.31 fromfpf32 F
+GLIBC_2.31 fromfpf32x F
+GLIBC_2.31 fromfpf64 F
+GLIBC_2.31 fromfpf64x F
+GLIBC_2.31 fromfpl F
+GLIBC_2.31 fromfpx F
+GLIBC_2.31 fromfpxf F
+GLIBC_2.31 fromfpxf128 F
+GLIBC_2.31 fromfpxf32 F
+GLIBC_2.31 fromfpxf32x F
+GLIBC_2.31 fromfpxf64 F
+GLIBC_2.31 fromfpxf64x F
+GLIBC_2.31 fromfpxl F
+GLIBC_2.31 fsub F
+GLIBC_2.31 fsubl F
+GLIBC_2.31 gamma F
+GLIBC_2.31 gammaf F
+GLIBC_2.31 gammal F
+GLIBC_2.31 getpayload F
+GLIBC_2.31 getpayloadf F
+GLIBC_2.31 getpayloadf128 F
+GLIBC_2.31 getpayloadf32 F
+GLIBC_2.31 getpayloadf32x F
+GLIBC_2.31 getpayloadf64 F
+GLIBC_2.31 getpayloadf64x F
+GLIBC_2.31 getpayloadl F
+GLIBC_2.31 hypot F
+GLIBC_2.31 hypotf F
+GLIBC_2.31 hypotf128 F
+GLIBC_2.31 hypotf32 F
+GLIBC_2.31 hypotf32x F
+GLIBC_2.31 hypotf64 F
+GLIBC_2.31 hypotf64x F
+GLIBC_2.31 hypotl F
+GLIBC_2.31 ilogb F
+GLIBC_2.31 ilogbf F
+GLIBC_2.31 ilogbf128 F
+GLIBC_2.31 ilogbf32 F
+GLIBC_2.31 ilogbf32x F
+GLIBC_2.31 ilogbf64 F
+GLIBC_2.31 ilogbf64x F
+GLIBC_2.31 ilogbl F
+GLIBC_2.31 j0 F
+GLIBC_2.31 j0f F
+GLIBC_2.31 j0f128 F
+GLIBC_2.31 j0f32 F
+GLIBC_2.31 j0f32x F
+GLIBC_2.31 j0f64 F
+GLIBC_2.31 j0f64x F
+GLIBC_2.31 j0l F
+GLIBC_2.31 j1 F
+GLIBC_2.31 j1f F
+GLIBC_2.31 j1f128 F
+GLIBC_2.31 j1f32 F
+GLIBC_2.31 j1f32x F
+GLIBC_2.31 j1f64 F
+GLIBC_2.31 j1f64x F
+GLIBC_2.31 j1l F
+GLIBC_2.31 jn F
+GLIBC_2.31 jnf F
+GLIBC_2.31 jnf128 F
+GLIBC_2.31 jnf32 F
+GLIBC_2.31 jnf32x F
+GLIBC_2.31 jnf64 F
+GLIBC_2.31 jnf64x F
+GLIBC_2.31 jnl F
+GLIBC_2.31 ldexp F
+GLIBC_2.31 ldexpf F
+GLIBC_2.31 ldexpf128 F
+GLIBC_2.31 ldexpf32 F
+GLIBC_2.31 ldexpf32x F
+GLIBC_2.31 ldexpf64 F
+GLIBC_2.31 ldexpf64x F
+GLIBC_2.31 ldexpl F
+GLIBC_2.31 lgamma F
+GLIBC_2.31 lgamma_r F
+GLIBC_2.31 lgammaf F
+GLIBC_2.31 lgammaf128 F
+GLIBC_2.31 lgammaf128_r F
+GLIBC_2.31 lgammaf32 F
+GLIBC_2.31 lgammaf32_r F
+GLIBC_2.31 lgammaf32x F
+GLIBC_2.31 lgammaf32x_r F
+GLIBC_2.31 lgammaf64 F
+GLIBC_2.31 lgammaf64_r F
+GLIBC_2.31 lgammaf64x F
+GLIBC_2.31 lgammaf64x_r F
+GLIBC_2.31 lgammaf_r F
+GLIBC_2.31 lgammal F
+GLIBC_2.31 lgammal_r F
+GLIBC_2.31 llogb F
+GLIBC_2.31 llogbf F
+GLIBC_2.31 llogbf128 F
+GLIBC_2.31 llogbf32 F
+GLIBC_2.31 llogbf32x F
+GLIBC_2.31 llogbf64 F
+GLIBC_2.31 llogbf64x F
+GLIBC_2.31 llogbl F
+GLIBC_2.31 llrint F
+GLIBC_2.31 llrintf F
+GLIBC_2.31 llrintf128 F
+GLIBC_2.31 llrintf32 F
+GLIBC_2.31 llrintf32x F
+GLIBC_2.31 llrintf64 F
+GLIBC_2.31 llrintf64x F
+GLIBC_2.31 llrintl F
+GLIBC_2.31 llround F
+GLIBC_2.31 llroundf F
+GLIBC_2.31 llroundf128 F
+GLIBC_2.31 llroundf32 F
+GLIBC_2.31 llroundf32x F
+GLIBC_2.31 llroundf64 F
+GLIBC_2.31 llroundf64x F
+GLIBC_2.31 llroundl F
+GLIBC_2.31 log F
+GLIBC_2.31 log10 F
+GLIBC_2.31 log10f F
+GLIBC_2.31 log10f128 F
+GLIBC_2.31 log10f32 F
+GLIBC_2.31 log10f32x F
+GLIBC_2.31 log10f64 F
+GLIBC_2.31 log10f64x F
+GLIBC_2.31 log10l F
+GLIBC_2.31 log1p F
+GLIBC_2.31 log1pf F
+GLIBC_2.31 log1pf128 F
+GLIBC_2.31 log1pf32 F
+GLIBC_2.31 log1pf32x F
+GLIBC_2.31 log1pf64 F
+GLIBC_2.31 log1pf64x F
+GLIBC_2.31 log1pl F
+GLIBC_2.31 log2 F
+GLIBC_2.31 log2f F
+GLIBC_2.31 log2f128 F
+GLIBC_2.31 log2f32 F
+GLIBC_2.31 log2f32x F
+GLIBC_2.31 log2f64 F
+GLIBC_2.31 log2f64x F
+GLIBC_2.31 log2l F
+GLIBC_2.31 logb F
+GLIBC_2.31 logbf F
+GLIBC_2.31 logbf128 F
+GLIBC_2.31 logbf32 F
+GLIBC_2.31 logbf32x F
+GLIBC_2.31 logbf64 F
+GLIBC_2.31 logbf64x F
+GLIBC_2.31 logbl F
+GLIBC_2.31 logf F
+GLIBC_2.31 logf128 F
+GLIBC_2.31 logf32 F
+GLIBC_2.31 logf32x F
+GLIBC_2.31 logf64 F
+GLIBC_2.31 logf64x F
+GLIBC_2.31 logl F
+GLIBC_2.31 lrint F
+GLIBC_2.31 lrintf F
+GLIBC_2.31 lrintf128 F
+GLIBC_2.31 lrintf32 F
+GLIBC_2.31 lrintf32x F
+GLIBC_2.31 lrintf64 F
+GLIBC_2.31 lrintf64x F
+GLIBC_2.31 lrintl F
+GLIBC_2.31 lround F
+GLIBC_2.31 lroundf F
+GLIBC_2.31 lroundf128 F
+GLIBC_2.31 lroundf32 F
+GLIBC_2.31 lroundf32x F
+GLIBC_2.31 lroundf64 F
+GLIBC_2.31 lroundf64x F
+GLIBC_2.31 lroundl F
+GLIBC_2.31 modf F
+GLIBC_2.31 modff F
+GLIBC_2.31 modff128 F
+GLIBC_2.31 modff32 F
+GLIBC_2.31 modff32x F
+GLIBC_2.31 modff64 F
+GLIBC_2.31 modff64x F
+GLIBC_2.31 modfl F
+GLIBC_2.31 nan F
+GLIBC_2.31 nanf F
+GLIBC_2.31 nanf128 F
+GLIBC_2.31 nanf32 F
+GLIBC_2.31 nanf32x F
+GLIBC_2.31 nanf64 F
+GLIBC_2.31 nanf64x F
+GLIBC_2.31 nanl F
+GLIBC_2.31 nearbyint F
+GLIBC_2.31 nearbyintf F
+GLIBC_2.31 nearbyintf128 F
+GLIBC_2.31 nearbyintf32 F
+GLIBC_2.31 nearbyintf32x F
+GLIBC_2.31 nearbyintf64 F
+GLIBC_2.31 nearbyintf64x F
+GLIBC_2.31 nearbyintl F
+GLIBC_2.31 nextafter F
+GLIBC_2.31 nextafterf F
+GLIBC_2.31 nextafterf128 F
+GLIBC_2.31 nextafterf32 F
+GLIBC_2.31 nextafterf32x F
+GLIBC_2.31 nextafterf64 F
+GLIBC_2.31 nextafterf64x F
+GLIBC_2.31 nextafterl F
+GLIBC_2.31 nextdown F
+GLIBC_2.31 nextdownf F
+GLIBC_2.31 nextdownf128 F
+GLIBC_2.31 nextdownf32 F
+GLIBC_2.31 nextdownf32x F
+GLIBC_2.31 nextdownf64 F
+GLIBC_2.31 nextdownf64x F
+GLIBC_2.31 nextdownl F
+GLIBC_2.31 nexttoward F
+GLIBC_2.31 nexttowardf F
+GLIBC_2.31 nexttowardl F
+GLIBC_2.31 nextup F
+GLIBC_2.31 nextupf F
+GLIBC_2.31 nextupf128 F
+GLIBC_2.31 nextupf32 F
+GLIBC_2.31 nextupf32x F
+GLIBC_2.31 nextupf64 F
+GLIBC_2.31 nextupf64x F
+GLIBC_2.31 nextupl F
+GLIBC_2.31 pow F
+GLIBC_2.31 powf F
+GLIBC_2.31 powf128 F
+GLIBC_2.31 powf32 F
+GLIBC_2.31 powf32x F
+GLIBC_2.31 powf64 F
+GLIBC_2.31 powf64x F
+GLIBC_2.31 powl F
+GLIBC_2.31 remainder F
+GLIBC_2.31 remainderf F
+GLIBC_2.31 remainderf128 F
+GLIBC_2.31 remainderf32 F
+GLIBC_2.31 remainderf32x F
+GLIBC_2.31 remainderf64 F
+GLIBC_2.31 remainderf64x F
+GLIBC_2.31 remainderl F
+GLIBC_2.31 remquo F
+GLIBC_2.31 remquof F
+GLIBC_2.31 remquof128 F
+GLIBC_2.31 remquof32 F
+GLIBC_2.31 remquof32x F
+GLIBC_2.31 remquof64 F
+GLIBC_2.31 remquof64x F
+GLIBC_2.31 remquol F
+GLIBC_2.31 rint F
+GLIBC_2.31 rintf F
+GLIBC_2.31 rintf128 F
+GLIBC_2.31 rintf32 F
+GLIBC_2.31 rintf32x F
+GLIBC_2.31 rintf64 F
+GLIBC_2.31 rintf64x F
+GLIBC_2.31 rintl F
+GLIBC_2.31 round F
+GLIBC_2.31 roundeven F
+GLIBC_2.31 roundevenf F
+GLIBC_2.31 roundevenf128 F
+GLIBC_2.31 roundevenf32 F
+GLIBC_2.31 roundevenf32x F
+GLIBC_2.31 roundevenf64 F
+GLIBC_2.31 roundevenf64x F
+GLIBC_2.31 roundevenl F
+GLIBC_2.31 roundf F
+GLIBC_2.31 roundf128 F
+GLIBC_2.31 roundf32 F
+GLIBC_2.31 roundf32x F
+GLIBC_2.31 roundf64 F
+GLIBC_2.31 roundf64x F
+GLIBC_2.31 roundl F
+GLIBC_2.31 scalb F
+GLIBC_2.31 scalbf F
+GLIBC_2.31 scalbl F
+GLIBC_2.31 scalbln F
+GLIBC_2.31 scalblnf F
+GLIBC_2.31 scalblnf128 F
+GLIBC_2.31 scalblnf32 F
+GLIBC_2.31 scalblnf32x F
+GLIBC_2.31 scalblnf64 F
+GLIBC_2.31 scalblnf64x F
+GLIBC_2.31 scalblnl F
+GLIBC_2.31 scalbn F
+GLIBC_2.31 scalbnf F
+GLIBC_2.31 scalbnf128 F
+GLIBC_2.31 scalbnf32 F
+GLIBC_2.31 scalbnf32x F
+GLIBC_2.31 scalbnf64 F
+GLIBC_2.31 scalbnf64x F
+GLIBC_2.31 scalbnl F
+GLIBC_2.31 setpayload F
+GLIBC_2.31 setpayloadf F
+GLIBC_2.31 setpayloadf128 F
+GLIBC_2.31 setpayloadf32 F
+GLIBC_2.31 setpayloadf32x F
+GLIBC_2.31 setpayloadf64 F
+GLIBC_2.31 setpayloadf64x F
+GLIBC_2.31 setpayloadl F
+GLIBC_2.31 setpayloadsig F
+GLIBC_2.31 setpayloadsigf F
+GLIBC_2.31 setpayloadsigf128 F
+GLIBC_2.31 setpayloadsigf32 F
+GLIBC_2.31 setpayloadsigf32x F
+GLIBC_2.31 setpayloadsigf64 F
+GLIBC_2.31 setpayloadsigf64x F
+GLIBC_2.31 setpayloadsigl F
+GLIBC_2.31 signgam D 0x4
+GLIBC_2.31 significand F
+GLIBC_2.31 significandf F
+GLIBC_2.31 significandl F
+GLIBC_2.31 sin F
+GLIBC_2.31 sincos F
+GLIBC_2.31 sincosf F
+GLIBC_2.31 sincosf128 F
+GLIBC_2.31 sincosf32 F
+GLIBC_2.31 sincosf32x F
+GLIBC_2.31 sincosf64 F
+GLIBC_2.31 sincosf64x F
+GLIBC_2.31 sincosl F
+GLIBC_2.31 sinf F
+GLIBC_2.31 sinf128 F
+GLIBC_2.31 sinf32 F
+GLIBC_2.31 sinf32x F
+GLIBC_2.31 sinf64 F
+GLIBC_2.31 sinf64x F
+GLIBC_2.31 sinh F
+GLIBC_2.31 sinhf F
+GLIBC_2.31 sinhf128 F
+GLIBC_2.31 sinhf32 F
+GLIBC_2.31 sinhf32x F
+GLIBC_2.31 sinhf64 F
+GLIBC_2.31 sinhf64x F
+GLIBC_2.31 sinhl F
+GLIBC_2.31 sinl F
+GLIBC_2.31 sqrt F
+GLIBC_2.31 sqrtf F
+GLIBC_2.31 sqrtf128 F
+GLIBC_2.31 sqrtf32 F
+GLIBC_2.31 sqrtf32x F
+GLIBC_2.31 sqrtf64 F
+GLIBC_2.31 sqrtf64x F
+GLIBC_2.31 sqrtl F
+GLIBC_2.31 tan F
+GLIBC_2.31 tanf F
+GLIBC_2.31 tanf128 F
+GLIBC_2.31 tanf32 F
+GLIBC_2.31 tanf32x F
+GLIBC_2.31 tanf64 F
+GLIBC_2.31 tanf64x F
+GLIBC_2.31 tanh F
+GLIBC_2.31 tanhf F
+GLIBC_2.31 tanhf128 F
+GLIBC_2.31 tanhf32 F
+GLIBC_2.31 tanhf32x F
+GLIBC_2.31 tanhf64 F
+GLIBC_2.31 tanhf64x F
+GLIBC_2.31 tanhl F
+GLIBC_2.31 tanl F
+GLIBC_2.31 tgamma F
+GLIBC_2.31 tgammaf F
+GLIBC_2.31 tgammaf128 F
+GLIBC_2.31 tgammaf32 F
+GLIBC_2.31 tgammaf32x F
+GLIBC_2.31 tgammaf64 F
+GLIBC_2.31 tgammaf64x F
+GLIBC_2.31 tgammal F
+GLIBC_2.31 totalorder F
+GLIBC_2.31 totalorderf F
+GLIBC_2.31 totalorderf128 F
+GLIBC_2.31 totalorderf32 F
+GLIBC_2.31 totalorderf32x F
+GLIBC_2.31 totalorderf64 F
+GLIBC_2.31 totalorderf64x F
+GLIBC_2.31 totalorderl F
+GLIBC_2.31 totalordermag F
+GLIBC_2.31 totalordermagf F
+GLIBC_2.31 totalordermagf128 F
+GLIBC_2.31 totalordermagf32 F
+GLIBC_2.31 totalordermagf32x F
+GLIBC_2.31 totalordermagf64 F
+GLIBC_2.31 totalordermagf64x F
+GLIBC_2.31 totalordermagl F
+GLIBC_2.31 trunc F
+GLIBC_2.31 truncf F
+GLIBC_2.31 truncf128 F
+GLIBC_2.31 truncf32 F
+GLIBC_2.31 truncf32x F
+GLIBC_2.31 truncf64 F
+GLIBC_2.31 truncf64x F
+GLIBC_2.31 truncl F
+GLIBC_2.31 ufromfp F
+GLIBC_2.31 ufromfpf F
+GLIBC_2.31 ufromfpf128 F
+GLIBC_2.31 ufromfpf32 F
+GLIBC_2.31 ufromfpf32x F
+GLIBC_2.31 ufromfpf64 F
+GLIBC_2.31 ufromfpf64x F
+GLIBC_2.31 ufromfpl F
+GLIBC_2.31 ufromfpx F
+GLIBC_2.31 ufromfpxf F
+GLIBC_2.31 ufromfpxf128 F
+GLIBC_2.31 ufromfpxf32 F
+GLIBC_2.31 ufromfpxf32x F
+GLIBC_2.31 ufromfpxf64 F
+GLIBC_2.31 ufromfpxf64x F
+GLIBC_2.31 ufromfpxl F
+GLIBC_2.31 y0 F
+GLIBC_2.31 y0f F
+GLIBC_2.31 y0f128 F
+GLIBC_2.31 y0f32 F
+GLIBC_2.31 y0f32x F
+GLIBC_2.31 y0f64 F
+GLIBC_2.31 y0f64x F
+GLIBC_2.31 y0l F
+GLIBC_2.31 y1 F
+GLIBC_2.31 y1f F
+GLIBC_2.31 y1f128 F
+GLIBC_2.31 y1f32 F
+GLIBC_2.31 y1f32x F
+GLIBC_2.31 y1f64 F
+GLIBC_2.31 y1f64x F
+GLIBC_2.31 y1l F
+GLIBC_2.31 yn F
+GLIBC_2.31 ynf F
+GLIBC_2.31 ynf128 F
+GLIBC_2.31 ynf32 F
+GLIBC_2.31 ynf32x F
+GLIBC_2.31 ynf64 F
+GLIBC_2.31 ynf64x F
+GLIBC_2.31 ynl F
diff --git a/sysdeps/unix/sysv/linux/riscv/libpthread.abilist b/sysdeps/unix/sysv/linux/riscv/libpthread.abilist
new file mode 100644
index 0000000000..b57b58a8cd
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/libpthread.abilist
@@ -0,0 +1,227 @@
+GLIBC_2.31 _IO_flockfile F
+GLIBC_2.31 _IO_ftrylockfile F
+GLIBC_2.31 _IO_funlockfile F
+GLIBC_2.31 __close F
+GLIBC_2.31 __connect F
+GLIBC_2.31 __errno_location F
+GLIBC_2.31 __h_errno_location F
+GLIBC_2.31 __libc_allocate_rtsig F
+GLIBC_2.31 __libc_current_sigrtmax F
+GLIBC_2.31 __libc_current_sigrtmin F
+GLIBC_2.31 __lseek F
+GLIBC_2.31 __open F
+GLIBC_2.31 __open64 F
+GLIBC_2.31 __pread64 F
+GLIBC_2.31 __pthread_cleanup_routine F
+GLIBC_2.31 __pthread_getspecific F
+GLIBC_2.31 __pthread_key_create F
+GLIBC_2.31 __pthread_mutex_destroy F
+GLIBC_2.31 __pthread_mutex_init F
+GLIBC_2.31 __pthread_mutex_lock F
+GLIBC_2.31 __pthread_mutex_trylock F
+GLIBC_2.31 __pthread_mutex_unlock F
+GLIBC_2.31 __pthread_mutexattr_destroy F
+GLIBC_2.31 __pthread_mutexattr_init F
+GLIBC_2.31 __pthread_mutexattr_settype F
+GLIBC_2.31 __pthread_once F
+GLIBC_2.31 __pthread_register_cancel F
+GLIBC_2.31 __pthread_register_cancel_defer F
+GLIBC_2.31 __pthread_rwlock_destroy F
+GLIBC_2.31 __pthread_rwlock_init F
+GLIBC_2.31 __pthread_rwlock_rdlock F
+GLIBC_2.31 __pthread_rwlock_tryrdlock F
+GLIBC_2.31 __pthread_rwlock_trywrlock F
+GLIBC_2.31 __pthread_rwlock_unlock F
+GLIBC_2.31 __pthread_rwlock_wrlock F
+GLIBC_2.31 __pthread_setspecific F
+GLIBC_2.31 __pthread_unregister_cancel F
+GLIBC_2.31 __pthread_unregister_cancel_restore F
+GLIBC_2.31 __pthread_unwind_next F
+GLIBC_2.31 __pwrite64 F
+GLIBC_2.31 __read F
+GLIBC_2.31 __res_state F
+GLIBC_2.31 __send F
+GLIBC_2.31 __sigaction F
+GLIBC_2.31 __write F
+GLIBC_2.31 _pthread_cleanup_pop F
+GLIBC_2.31 _pthread_cleanup_pop_restore F
+GLIBC_2.31 _pthread_cleanup_push F
+GLIBC_2.31 _pthread_cleanup_push_defer F
+GLIBC_2.31 accept F
+GLIBC_2.31 call_once F
+GLIBC_2.31 close F
+GLIBC_2.31 cnd_broadcast F
+GLIBC_2.31 cnd_destroy F
+GLIBC_2.31 cnd_init F
+GLIBC_2.31 cnd_signal F
+GLIBC_2.31 cnd_timedwait F
+GLIBC_2.31 cnd_wait F
+GLIBC_2.31 connect F
+GLIBC_2.31 flockfile F
+GLIBC_2.31 fsync F
+GLIBC_2.31 ftrylockfile F
+GLIBC_2.31 funlockfile F
+GLIBC_2.31 lseek F
+GLIBC_2.31 lseek64 F
+GLIBC_2.31 msync F
+GLIBC_2.31 mtx_destroy F
+GLIBC_2.31 mtx_init F
+GLIBC_2.31 mtx_lock F
+GLIBC_2.31 mtx_timedlock F
+GLIBC_2.31 mtx_trylock F
+GLIBC_2.31 mtx_unlock F
+GLIBC_2.31 open F
+GLIBC_2.31 open64 F
+GLIBC_2.31 pause F
+GLIBC_2.31 pread F
+GLIBC_2.31 pread64 F
+GLIBC_2.31 pthread_attr_getaffinity_np F
+GLIBC_2.31 pthread_attr_getguardsize F
+GLIBC_2.31 pthread_attr_getschedpolicy F
+GLIBC_2.31 pthread_attr_getscope F
+GLIBC_2.31 pthread_attr_getstack F
+GLIBC_2.31 pthread_attr_getstackaddr F
+GLIBC_2.31 pthread_attr_getstacksize F
+GLIBC_2.31 pthread_attr_setaffinity_np F
+GLIBC_2.31 pthread_attr_setguardsize F
+GLIBC_2.31 pthread_attr_setschedpolicy F
+GLIBC_2.31 pthread_attr_setscope F
+GLIBC_2.31 pthread_attr_setstack F
+GLIBC_2.31 pthread_attr_setstackaddr F
+GLIBC_2.31 pthread_attr_setstacksize F
+GLIBC_2.31 pthread_barrier_destroy F
+GLIBC_2.31 pthread_barrier_init F
+GLIBC_2.31 pthread_barrier_wait F
+GLIBC_2.31 pthread_barrierattr_destroy F
+GLIBC_2.31 pthread_barrierattr_getpshared F
+GLIBC_2.31 pthread_barrierattr_init F
+GLIBC_2.31 pthread_barrierattr_setpshared F
+GLIBC_2.31 pthread_cancel F
+GLIBC_2.31 pthread_clockjoin_np F
+GLIBC_2.31 pthread_cond_broadcast F
+GLIBC_2.31 pthread_cond_clockwait F
+GLIBC_2.31 pthread_cond_destroy F
+GLIBC_2.31 pthread_cond_init F
+GLIBC_2.31 pthread_cond_signal F
+GLIBC_2.31 pthread_cond_timedwait F
+GLIBC_2.31 pthread_cond_wait F
+GLIBC_2.31 pthread_condattr_destroy F
+GLIBC_2.31 pthread_condattr_getclock F
+GLIBC_2.31 pthread_condattr_getpshared F
+GLIBC_2.31 pthread_condattr_init F
+GLIBC_2.31 pthread_condattr_setclock F
+GLIBC_2.31 pthread_condattr_setpshared F
+GLIBC_2.31 pthread_create F
+GLIBC_2.31 pthread_detach F
+GLIBC_2.31 pthread_exit F
+GLIBC_2.31 pthread_getaffinity_np F
+GLIBC_2.31 pthread_getattr_default_np F
+GLIBC_2.31 pthread_getattr_np F
+GLIBC_2.31 pthread_getconcurrency F
+GLIBC_2.31 pthread_getcpuclockid F
+GLIBC_2.31 pthread_getname_np F
+GLIBC_2.31 pthread_getschedparam F
+GLIBC_2.31 pthread_getspecific F
+GLIBC_2.31 pthread_join F
+GLIBC_2.31 pthread_key_create F
+GLIBC_2.31 pthread_key_delete F
+GLIBC_2.31 pthread_kill F
+GLIBC_2.31 pthread_kill_other_threads_np F
+GLIBC_2.31 pthread_mutex_clocklock F
+GLIBC_2.31 pthread_mutex_consistent F
+GLIBC_2.31 pthread_mutex_consistent_np F
+GLIBC_2.31 pthread_mutex_destroy F
+GLIBC_2.31 pthread_mutex_getprioceiling F
+GLIBC_2.31 pthread_mutex_init F
+GLIBC_2.31 pthread_mutex_lock F
+GLIBC_2.31 pthread_mutex_setprioceiling F
+GLIBC_2.31 pthread_mutex_timedlock F
+GLIBC_2.31 pthread_mutex_trylock F
+GLIBC_2.31 pthread_mutex_unlock F
+GLIBC_2.31 pthread_mutexattr_destroy F
+GLIBC_2.31 pthread_mutexattr_getkind_np F
+GLIBC_2.31 pthread_mutexattr_getprioceiling F
+GLIBC_2.31 pthread_mutexattr_getprotocol F
+GLIBC_2.31 pthread_mutexattr_getpshared F
+GLIBC_2.31 pthread_mutexattr_getrobust F
+GLIBC_2.31 pthread_mutexattr_getrobust_np F
+GLIBC_2.31 pthread_mutexattr_gettype F
+GLIBC_2.31 pthread_mutexattr_init F
+GLIBC_2.31 pthread_mutexattr_setkind_np F
+GLIBC_2.31 pthread_mutexattr_setprioceiling F
+GLIBC_2.31 pthread_mutexattr_setprotocol F
+GLIBC_2.31 pthread_mutexattr_setpshared F
+GLIBC_2.31 pthread_mutexattr_setrobust F
+GLIBC_2.31 pthread_mutexattr_setrobust_np F
+GLIBC_2.31 pthread_mutexattr_settype F
+GLIBC_2.31 pthread_once F
+GLIBC_2.31 pthread_rwlock_clockrdlock F
+GLIBC_2.31 pthread_rwlock_clockwrlock F
+GLIBC_2.31 pthread_rwlock_destroy F
+GLIBC_2.31 pthread_rwlock_init F
+GLIBC_2.31 pthread_rwlock_rdlock F
+GLIBC_2.31 pthread_rwlock_timedrdlock F
+GLIBC_2.31 pthread_rwlock_timedwrlock F
+GLIBC_2.31 pthread_rwlock_tryrdlock F
+GLIBC_2.31 pthread_rwlock_trywrlock F
+GLIBC_2.31 pthread_rwlock_unlock F
+GLIBC_2.31 pthread_rwlock_wrlock F
+GLIBC_2.31 pthread_rwlockattr_destroy F
+GLIBC_2.31 pthread_rwlockattr_getkind_np F
+GLIBC_2.31 pthread_rwlockattr_getpshared F
+GLIBC_2.31 pthread_rwlockattr_init F
+GLIBC_2.31 pthread_rwlockattr_setkind_np F
+GLIBC_2.31 pthread_rwlockattr_setpshared F
+GLIBC_2.31 pthread_setaffinity_np F
+GLIBC_2.31 pthread_setattr_default_np F
+GLIBC_2.31 pthread_setcancelstate F
+GLIBC_2.31 pthread_setcanceltype F
+GLIBC_2.31 pthread_setconcurrency F
+GLIBC_2.31 pthread_setname_np F
+GLIBC_2.31 pthread_setschedparam F
+GLIBC_2.31 pthread_setschedprio F
+GLIBC_2.31 pthread_setspecific F
+GLIBC_2.31 pthread_sigmask F
+GLIBC_2.31 pthread_sigqueue F
+GLIBC_2.31 pthread_spin_destroy F
+GLIBC_2.31 pthread_spin_init F
+GLIBC_2.31 pthread_spin_lock F
+GLIBC_2.31 pthread_spin_trylock F
+GLIBC_2.31 pthread_spin_unlock F
+GLIBC_2.31 pthread_testcancel F
+GLIBC_2.31 pthread_timedjoin_np F
+GLIBC_2.31 pthread_tryjoin_np F
+GLIBC_2.31 pthread_yield F
+GLIBC_2.31 pwrite F
+GLIBC_2.31 pwrite64 F
+GLIBC_2.31 raise F
+GLIBC_2.31 read F
+GLIBC_2.31 recv F
+GLIBC_2.31 recvfrom F
+GLIBC_2.31 recvmsg F
+GLIBC_2.31 sem_clockwait F
+GLIBC_2.31 sem_close F
+GLIBC_2.31 sem_destroy F
+GLIBC_2.31 sem_getvalue F
+GLIBC_2.31 sem_init F
+GLIBC_2.31 sem_open F
+GLIBC_2.31 sem_post F
+GLIBC_2.31 sem_timedwait F
+GLIBC_2.31 sem_trywait F
+GLIBC_2.31 sem_unlink F
+GLIBC_2.31 sem_wait F
+GLIBC_2.31 send F
+GLIBC_2.31 sendmsg F
+GLIBC_2.31 sendto F
+GLIBC_2.31 sigaction F
+GLIBC_2.31 sigwait F
+GLIBC_2.31 tcdrain F
+GLIBC_2.31 thrd_create F
+GLIBC_2.31 thrd_detach F
+GLIBC_2.31 thrd_exit F
+GLIBC_2.31 thrd_join F
+GLIBC_2.31 tss_create F
+GLIBC_2.31 tss_delete F
+GLIBC_2.31 tss_get F
+GLIBC_2.31 tss_set F
+GLIBC_2.31 write F
diff --git a/sysdeps/unix/sysv/linux/riscv/libresolv.abilist b/sysdeps/unix/sysv/linux/riscv/libresolv.abilist
new file mode 100644
index 0000000000..acd0b2e2de
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/libresolv.abilist
@@ -0,0 +1,79 @@
+GLIBC_2.31 __b64_ntop F
+GLIBC_2.31 __b64_pton F
+GLIBC_2.31 __dn_comp F
+GLIBC_2.31 __dn_count_labels F
+GLIBC_2.31 __dn_expand F
+GLIBC_2.31 __dn_skipname F
+GLIBC_2.31 __fp_nquery F
+GLIBC_2.31 __fp_query F
+GLIBC_2.31 __fp_resstat F
+GLIBC_2.31 __hostalias F
+GLIBC_2.31 __loc_aton F
+GLIBC_2.31 __loc_ntoa F
+GLIBC_2.31 __p_cdname F
+GLIBC_2.31 __p_cdnname F
+GLIBC_2.31 __p_class F
+GLIBC_2.31 __p_class_syms D 0x54
+GLIBC_2.31 __p_fqname F
+GLIBC_2.31 __p_fqnname F
+GLIBC_2.31 __p_option F
+GLIBC_2.31 __p_query F
+GLIBC_2.31 __p_rcode F
+GLIBC_2.31 __p_time F
+GLIBC_2.31 __p_type F
+GLIBC_2.31 __p_type_syms D 0x228
+GLIBC_2.31 __putlong F
+GLIBC_2.31 __putshort F
+GLIBC_2.31 __res_close F
+GLIBC_2.31 __res_dnok F
+GLIBC_2.31 __res_hnok F
+GLIBC_2.31 __res_hostalias F
+GLIBC_2.31 __res_isourserver F
+GLIBC_2.31 __res_mailok F
+GLIBC_2.31 __res_mkquery F
+GLIBC_2.31 __res_nameinquery F
+GLIBC_2.31 __res_nmkquery F
+GLIBC_2.31 __res_nquery F
+GLIBC_2.31 __res_nquerydomain F
+GLIBC_2.31 __res_nsearch F
+GLIBC_2.31 __res_nsend F
+GLIBC_2.31 __res_ownok F
+GLIBC_2.31 __res_queriesmatch F
+GLIBC_2.31 __res_query F
+GLIBC_2.31 __res_querydomain F
+GLIBC_2.31 __res_search F
+GLIBC_2.31 __res_send F
+GLIBC_2.31 __sym_ntop F
+GLIBC_2.31 __sym_ntos F
+GLIBC_2.31 __sym_ston F
+GLIBC_2.31 _getlong F
+GLIBC_2.31 _getshort F
+GLIBC_2.31 inet_net_ntop F
+GLIBC_2.31 inet_net_pton F
+GLIBC_2.31 inet_neta F
+GLIBC_2.31 ns_datetosecs F
+GLIBC_2.31 ns_format_ttl F
+GLIBC_2.31 ns_get16 F
+GLIBC_2.31 ns_get32 F
+GLIBC_2.31 ns_initparse F
+GLIBC_2.31 ns_makecanon F
+GLIBC_2.31 ns_msg_getflag F
+GLIBC_2.31 ns_name_compress F
+GLIBC_2.31 ns_name_ntol F
+GLIBC_2.31 ns_name_ntop F
+GLIBC_2.31 ns_name_pack F
+GLIBC_2.31 ns_name_pton F
+GLIBC_2.31 ns_name_rollback F
+GLIBC_2.31 ns_name_skip F
+GLIBC_2.31 ns_name_uncompress F
+GLIBC_2.31 ns_name_unpack F
+GLIBC_2.31 ns_parse_ttl F
+GLIBC_2.31 ns_parserr F
+GLIBC_2.31 ns_put16 F
+GLIBC_2.31 ns_put32 F
+GLIBC_2.31 ns_samedomain F
+GLIBC_2.31 ns_samename F
+GLIBC_2.31 ns_skiprr F
+GLIBC_2.31 ns_sprintrr F
+GLIBC_2.31 ns_sprintrrf F
+GLIBC_2.31 ns_subdomain F
diff --git a/sysdeps/unix/sysv/linux/riscv/librt.abilist b/sysdeps/unix/sysv/linux/riscv/librt.abilist
new file mode 100644
index 0000000000..54f9db7c99
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/librt.abilist
@@ -0,0 +1,35 @@
+GLIBC_2.31 __mq_open_2 F
+GLIBC_2.31 aio_cancel F
+GLIBC_2.31 aio_cancel64 F
+GLIBC_2.31 aio_error F
+GLIBC_2.31 aio_error64 F
+GLIBC_2.31 aio_fsync F
+GLIBC_2.31 aio_fsync64 F
+GLIBC_2.31 aio_init F
+GLIBC_2.31 aio_read F
+GLIBC_2.31 aio_read64 F
+GLIBC_2.31 aio_return F
+GLIBC_2.31 aio_return64 F
+GLIBC_2.31 aio_suspend F
+GLIBC_2.31 aio_suspend64 F
+GLIBC_2.31 aio_write F
+GLIBC_2.31 aio_write64 F
+GLIBC_2.31 lio_listio F
+GLIBC_2.31 lio_listio64 F
+GLIBC_2.31 mq_close F
+GLIBC_2.31 mq_getattr F
+GLIBC_2.31 mq_notify F
+GLIBC_2.31 mq_open F
+GLIBC_2.31 mq_receive F
+GLIBC_2.31 mq_send F
+GLIBC_2.31 mq_setattr F
+GLIBC_2.31 mq_timedreceive F
+GLIBC_2.31 mq_timedsend F
+GLIBC_2.31 mq_unlink F
+GLIBC_2.31 shm_open F
+GLIBC_2.31 shm_unlink F
+GLIBC_2.31 timer_create F
+GLIBC_2.31 timer_delete F
+GLIBC_2.31 timer_getoverrun F
+GLIBC_2.31 timer_gettime F
+GLIBC_2.31 timer_settime F
diff --git a/sysdeps/unix/sysv/linux/riscv/libthread_db.abilist b/sysdeps/unix/sysv/linux/riscv/libthread_db.abilist
new file mode 100644
index 0000000000..95f6fb7aab
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/libthread_db.abilist
@@ -0,0 +1,40 @@
+GLIBC_2.31 td_init F
+GLIBC_2.31 td_log F
+GLIBC_2.31 td_symbol_list F
+GLIBC_2.31 td_ta_clear_event F
+GLIBC_2.31 td_ta_delete F
+GLIBC_2.31 td_ta_enable_stats F
+GLIBC_2.31 td_ta_event_addr F
+GLIBC_2.31 td_ta_event_getmsg F
+GLIBC_2.31 td_ta_get_nthreads F
+GLIBC_2.31 td_ta_get_ph F
+GLIBC_2.31 td_ta_get_stats F
+GLIBC_2.31 td_ta_map_id2thr F
+GLIBC_2.31 td_ta_map_lwp2thr F
+GLIBC_2.31 td_ta_new F
+GLIBC_2.31 td_ta_reset_stats F
+GLIBC_2.31 td_ta_set_event F
+GLIBC_2.31 td_ta_setconcurrency F
+GLIBC_2.31 td_ta_thr_iter F
+GLIBC_2.31 td_ta_tsd_iter F
+GLIBC_2.31 td_thr_clear_event F
+GLIBC_2.31 td_thr_dbresume F
+GLIBC_2.31 td_thr_dbsuspend F
+GLIBC_2.31 td_thr_event_enable F
+GLIBC_2.31 td_thr_event_getmsg F
+GLIBC_2.31 td_thr_get_info F
+GLIBC_2.31 td_thr_getfpregs F
+GLIBC_2.31 td_thr_getgregs F
+GLIBC_2.31 td_thr_getxregs F
+GLIBC_2.31 td_thr_getxregsize F
+GLIBC_2.31 td_thr_set_event F
+GLIBC_2.31 td_thr_setfpregs F
+GLIBC_2.31 td_thr_setgregs F
+GLIBC_2.31 td_thr_setprio F
+GLIBC_2.31 td_thr_setsigpending F
+GLIBC_2.31 td_thr_setxregs F
+GLIBC_2.31 td_thr_sigsetmask F
+GLIBC_2.31 td_thr_tls_get_addr F
+GLIBC_2.31 td_thr_tlsbase F
+GLIBC_2.31 td_thr_tsd F
+GLIBC_2.31 td_thr_validate F
diff --git a/sysdeps/unix/sysv/linux/riscv/libutil.abilist b/sysdeps/unix/sysv/linux/riscv/libutil.abilist
new file mode 100644
index 0000000000..9eb091a2d5
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/riscv/libutil.abilist
@@ -0,0 +1,6 @@
+GLIBC_2.31 forkpty F
+GLIBC_2.31 login F
+GLIBC_2.31 login_tty F
+GLIBC_2.31 logout F
+GLIBC_2.31 logwtmp F
+GLIBC_2.31 openpty F
--
2.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* [RFC v6 17/23] RISC-V: Add the RV32 libm-test-ulps
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (15 preceding siblings ...)
2020-01-12 10:34 ` [RFC v6 16/23] RISC-V: Add ABI lists Alistair Francis
@ 2020-01-12 10:34 ` Alistair Francis
2020-01-12 10:34 ` [RFC v6 18/23] RISC-V: Fix llrint and llround missing exceptions on RV32 Alistair Francis
` (6 subsequent siblings)
23 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:34 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
Add a libm-test-ulps for RV32, generated by running `make regen-ulps`.
This is different to the RV64 one.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
sysdeps/riscv/rv32/rvd/libm-test-ulps | 2214 ++++++++++++++++++++
sysdeps/riscv/rv32/rvd/libm-test-ulps-name | 1 +
2 files changed, 2215 insertions(+)
create mode 100644 sysdeps/riscv/rv32/rvd/libm-test-ulps
create mode 100644 sysdeps/riscv/rv32/rvd/libm-test-ulps-name
diff --git a/sysdeps/riscv/rv32/rvd/libm-test-ulps b/sysdeps/riscv/rv32/rvd/libm-test-ulps
new file mode 100644
index 0000000000..3e702da660
--- /dev/null
+++ b/sysdeps/riscv/rv32/rvd/libm-test-ulps
@@ -0,0 +1,2214 @@
+# Begin of automatic generation
+
+# Maximal error of functions:
+Function: "acos":
+float: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "acos_downward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "acos_towardzero":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "acos_upward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "acosh":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: "acosh_downward":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: "acosh_towardzero":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: "acosh_upward":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 4
+
+Function: "asin":
+float: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "asin_downward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "asin_towardzero":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "asin_upward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "asinh":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 3
+ldouble: 3
+
+Function: "asinh_downward":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 4
+ldouble: 4
+
+Function: "asinh_towardzero":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 3
+
+Function: "asinh_upward":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 4
+ldouble: 4
+
+Function: "atan":
+float: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "atan2":
+float: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "atan2_downward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: "atan2_towardzero":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: "atan2_upward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "atan_downward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: "atan_towardzero":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "atan_upward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: "atanh":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: "atanh_downward":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 4
+ldouble: 4
+
+Function: "atanh_towardzero":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: "atanh_upward":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 4
+ldouble: 4
+
+Function: "cabs":
+double: 1
+idouble: 1
+ildouble: 1
+ldouble: 1
+
+Function: "cabs_downward":
+double: 1
+idouble: 1
+ildouble: 1
+ldouble: 1
+
+Function: "cabs_towardzero":
+double: 1
+idouble: 1
+ildouble: 1
+ldouble: 1
+
+Function: "cabs_upward":
+double: 1
+idouble: 1
+ildouble: 1
+ldouble: 1
+
+Function: Real part of "cacos":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "cacos":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "cacos_downward":
+double: 3
+float: 2
+idouble: 3
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: Imaginary part of "cacos_downward":
+double: 5
+float: 3
+idouble: 5
+ifloat: 3
+ildouble: 6
+ldouble: 6
+
+Function: Real part of "cacos_towardzero":
+double: 3
+float: 2
+idouble: 3
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: Imaginary part of "cacos_towardzero":
+double: 4
+float: 2
+idouble: 4
+ifloat: 2
+ildouble: 5
+ldouble: 5
+
+Function: Real part of "cacos_upward":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 3
+ldouble: 4
+
+Function: Imaginary part of "cacos_upward":
+double: 5
+float: 5
+idouble: 5
+ifloat: 5
+ildouble: 7
+ldouble: 7
+
+Function: Real part of "cacosh":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "cacosh":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "cacosh_downward":
+double: 4
+float: 2
+idouble: 4
+ifloat: 2
+ildouble: 5
+ldouble: 5
+
+Function: Imaginary part of "cacosh_downward":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 4
+ldouble: 4
+
+Function: Real part of "cacosh_towardzero":
+double: 4
+float: 2
+idouble: 4
+ifloat: 2
+ildouble: 5
+ldouble: 5
+
+Function: Imaginary part of "cacosh_towardzero":
+double: 3
+float: 2
+idouble: 3
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: Real part of "cacosh_upward":
+double: 4
+float: 3
+idouble: 4
+ifloat: 3
+ildouble: 6
+ldouble: 6
+
+Function: Imaginary part of "cacosh_upward":
+double: 3
+float: 3
+idouble: 3
+ifloat: 2
+ildouble: 4
+ldouble: 4
+
+Function: "carg":
+float: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "carg_downward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: "carg_towardzero":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: "carg_upward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "casin":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "casin":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "casin_downward":
+double: 3
+float: 2
+idouble: 3
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: Imaginary part of "casin_downward":
+double: 5
+float: 3
+idouble: 5
+ifloat: 3
+ildouble: 6
+ldouble: 6
+
+Function: Real part of "casin_towardzero":
+double: 3
+float: 1
+idouble: 3
+ifloat: 1
+ildouble: 3
+ldouble: 3
+
+Function: Imaginary part of "casin_towardzero":
+double: 4
+float: 2
+idouble: 4
+ifloat: 2
+ildouble: 5
+ldouble: 5
+
+Function: Real part of "casin_upward":
+double: 3
+float: 2
+idouble: 3
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: Imaginary part of "casin_upward":
+double: 5
+float: 5
+idouble: 5
+ifloat: 5
+ildouble: 7
+ldouble: 7
+
+Function: Real part of "casinh":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "casinh":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "casinh_downward":
+double: 5
+float: 3
+idouble: 5
+ifloat: 3
+ildouble: 6
+ldouble: 6
+
+Function: Imaginary part of "casinh_downward":
+double: 3
+float: 2
+idouble: 3
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: Real part of "casinh_towardzero":
+double: 4
+float: 2
+idouble: 4
+ifloat: 2
+ildouble: 5
+ldouble: 5
+
+Function: Imaginary part of "casinh_towardzero":
+double: 3
+float: 1
+idouble: 3
+ifloat: 1
+ildouble: 3
+ldouble: 3
+
+Function: Real part of "casinh_upward":
+double: 5
+float: 5
+idouble: 5
+ifloat: 5
+ildouble: 7
+ldouble: 7
+
+Function: Imaginary part of "casinh_upward":
+double: 3
+float: 2
+idouble: 3
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: Real part of "catan":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: Imaginary part of "catan":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: Real part of "catan_downward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "catan_downward":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "catan_towardzero":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "catan_towardzero":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "catan_upward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "catan_upward":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: Real part of "catanh":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: Imaginary part of "catanh":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: Real part of "catanh_downward":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "catanh_downward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "catanh_towardzero":
+double: 3
+float: 3
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 3
+
+Function: Imaginary part of "catanh_towardzero":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "catanh_upward":
+double: 4
+float: 4
+idouble: 4
+ifloat: 4
+ildouble: 4
+ldouble: 4
+
+Function: Imaginary part of "catanh_upward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "cbrt":
+double: 3
+float: 1
+idouble: 3
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "cbrt_downward":
+double: 4
+float: 1
+idouble: 4
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "cbrt_towardzero":
+double: 3
+float: 1
+idouble: 3
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "cbrt_upward":
+double: 5
+float: 1
+idouble: 5
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: Real part of "ccos":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: Imaginary part of "ccos":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: Real part of "ccos_downward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "ccos_downward":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "ccos_towardzero":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "ccos_towardzero":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "ccos_upward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: Imaginary part of "ccos_upward":
+double: 2
+float: 2
+idouble: 2
+ifloat: 4
+ildouble: 3
+ldouble: 3
+
+Function: Real part of "ccosh":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: Imaginary part of "ccosh":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: Real part of "ccosh_downward":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "ccosh_downward":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "ccosh_towardzero":
+double: 2
+float: 3
+idouble: 2
+ifloat: 3
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "ccosh_towardzero":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "ccosh_upward":
+double: 3
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: Imaginary part of "ccosh_upward":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "cexp":
+double: 2
+float: 1
+idouble: 2
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: Imaginary part of "cexp":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 1
+ldouble: 1
+
+Function: Real part of "cexp_downward":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "cexp_downward":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "cexp_towardzero":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "cexp_towardzero":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "cexp_upward":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: Imaginary part of "cexp_upward":
+double: 3
+float: 2
+idouble: 3
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: Real part of "clog":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "clog":
+float: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: Real part of "clog10":
+double: 3
+float: 4
+idouble: 3
+ifloat: 4
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "clog10":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "clog10_downward":
+double: 5
+float: 5
+idouble: 5
+ifloat: 5
+ildouble: 3
+ldouble: 3
+
+Function: Imaginary part of "clog10_downward":
+double: 2
+float: 4
+idouble: 2
+ifloat: 4
+ildouble: 3
+ldouble: 3
+
+Function: Real part of "clog10_towardzero":
+double: 5
+float: 5
+idouble: 5
+ifloat: 6
+ildouble: 4
+ldouble: 4
+
+Function: Imaginary part of "clog10_towardzero":
+double: 2
+float: 4
+idouble: 2
+ifloat: 4
+ildouble: 3
+ldouble: 3
+
+Function: Real part of "clog10_upward":
+double: 6
+float: 5
+idouble: 6
+ifloat: 6
+ildouble: 4
+ldouble: 4
+
+Function: Imaginary part of "clog10_upward":
+double: 2
+float: 4
+idouble: 3
+ifloat: 5
+ildouble: 3
+ldouble: 4
+
+Function: Real part of "clog_downward":
+double: 4
+float: 3
+idouble: 4
+ifloat: 3
+ildouble: 3
+ldouble: 3
+
+Function: Imaginary part of "clog_downward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "clog_towardzero":
+double: 4
+float: 4
+idouble: 4
+ifloat: 4
+ildouble: 3
+ldouble: 3
+
+Function: Imaginary part of "clog_towardzero":
+double: 1
+float: 3
+idouble: 1
+ifloat: 3
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "clog_upward":
+double: 4
+float: 3
+idouble: 4
+ifloat: 3
+ildouble: 4
+ldouble: 4
+
+Function: Imaginary part of "clog_upward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 3
+ldouble: 2
+
+Function: "cos":
+double: 1
+idouble: 1
+ildouble: 1
+ldouble: 1
+
+Function: "cos_downward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 3
+ldouble: 3
+
+Function: "cos_towardzero":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "cos_upward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "cosh":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "cosh_downward":
+double: 2
+float: 1
+idouble: 2
+ifloat: 1
+ildouble: 1
+ldouble: 2
+
+Function: "cosh_towardzero":
+double: 2
+float: 1
+idouble: 2
+ifloat: 1
+ildouble: 1
+ldouble: 2
+
+Function: "cosh_upward":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 1
+ldouble: 3
+
+Function: Real part of "cpow":
+double: 2
+float: 5
+idouble: 2
+ifloat: 5
+ildouble: 4
+ldouble: 4
+
+Function: Imaginary part of "cpow":
+float: 2
+ifloat: 2
+ildouble: 1
+ldouble: 1
+
+Function: Real part of "cpow_downward":
+double: 5
+float: 8
+idouble: 5
+ifloat: 8
+ildouble: 6
+ldouble: 6
+
+Function: Imaginary part of "cpow_downward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "cpow_towardzero":
+double: 5
+float: 8
+idouble: 5
+ifloat: 8
+ildouble: 6
+ldouble: 6
+
+Function: Imaginary part of "cpow_towardzero":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "cpow_upward":
+double: 4
+float: 1
+idouble: 4
+ifloat: 1
+ildouble: 3
+ldouble: 3
+
+Function: Imaginary part of "cpow_upward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "csin":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: Imaginary part of "csin":
+ildouble: 1
+ldouble: 1
+
+Function: Real part of "csin_downward":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "csin_downward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "csin_towardzero":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "csin_towardzero":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "csin_upward":
+double: 4
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "csin_upward":
+double: 2
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: Real part of "csinh":
+float: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: Imaginary part of "csinh":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: Real part of "csinh_downward":
+double: 2
+float: 1
+idouble: 2
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "csinh_downward":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "csinh_towardzero":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "csinh_towardzero":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "csinh_upward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: Imaginary part of "csinh_upward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "csqrt":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Imaginary part of "csqrt":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: Real part of "csqrt_downward":
+double: 5
+float: 4
+idouble: 5
+ifloat: 4
+ildouble: 4
+ldouble: 4
+
+Function: Imaginary part of "csqrt_downward":
+double: 4
+float: 3
+idouble: 4
+ifloat: 3
+ildouble: 3
+ldouble: 3
+
+Function: Real part of "csqrt_towardzero":
+double: 4
+float: 3
+idouble: 4
+ifloat: 3
+ildouble: 3
+ldouble: 3
+
+Function: Imaginary part of "csqrt_towardzero":
+double: 4
+float: 3
+idouble: 4
+ifloat: 3
+ildouble: 3
+ldouble: 3
+
+Function: Real part of "csqrt_upward":
+double: 5
+float: 4
+idouble: 5
+ifloat: 4
+ildouble: 4
+ldouble: 4
+
+Function: Imaginary part of "csqrt_upward":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 3
+ldouble: 3
+
+Function: Real part of "ctan":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 3
+ldouble: 3
+
+Function: Imaginary part of "ctan":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: Real part of "ctan_downward":
+double: 6
+float: 5
+idouble: 6
+ifloat: 5
+ildouble: 4
+ldouble: 4
+
+Function: Imaginary part of "ctan_downward":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 5
+ldouble: 5
+
+Function: Real part of "ctan_towardzero":
+double: 5
+float: 2
+idouble: 5
+ifloat: 2
+ildouble: 4
+ldouble: 4
+
+Function: Imaginary part of "ctan_towardzero":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 5
+ldouble: 5
+
+Function: Real part of "ctan_upward":
+double: 2
+float: 4
+idouble: 2
+ifloat: 4
+ildouble: 5
+ldouble: 5
+
+Function: Imaginary part of "ctan_upward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 5
+ldouble: 5
+
+Function: Real part of "ctanh":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: Imaginary part of "ctanh":
+double: 2
+float: 1
+idouble: 2
+ifloat: 1
+ildouble: 3
+ldouble: 3
+
+Function: Real part of "ctanh_downward":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 5
+ldouble: 5
+
+Function: Imaginary part of "ctanh_downward":
+double: 6
+float: 5
+idouble: 6
+ifloat: 5
+ildouble: 4
+ldouble: 4
+
+Function: Real part of "ctanh_towardzero":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 5
+ldouble: 5
+
+Function: Imaginary part of "ctanh_towardzero":
+double: 5
+float: 2
+idouble: 7
+ifloat: 2
+ildouble: 5
+ldouble: 3
+
+Function: Real part of "ctanh_upward":
+double: 1
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 5
+ldouble: 5
+
+Function: Imaginary part of "ctanh_upward":
+double: 3
+float: 6
+idouble: 7
+ifloat: 3
+ildouble: 5
+ldouble: 5
+
+Function: "erf":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "erf_downward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "erf_towardzero":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "erf_upward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "erfc":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: "erfc_downward":
+double: 4
+float: 4
+idouble: 4
+ifloat: 4
+ildouble: 5
+ldouble: 5
+
+Function: "erfc_towardzero":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 4
+ldouble: 5
+
+Function: "erfc_upward":
+double: 4
+float: 4
+idouble: 4
+ifloat: 4
+ildouble: 5
+ldouble: 6
+
+Function: "exp":
+ildouble: 1
+ldouble: 1
+
+Function: "exp10":
+double: 2
+idouble: 2
+ildouble: 2
+ldouble: 2
+
+Function: "exp10_downward":
+double: 3
+idouble: 3
+ildouble: 3
+ldouble: 3
+
+Function: "exp10_towardzero":
+double: 3
+idouble: 3
+ildouble: 3
+ldouble: 3
+
+Function: "exp10_upward":
+double: 2
+float: 1
+idouble: 3
+ifloat: 1
+ildouble: 3
+ldouble: 4
+
+Function: "exp2":
+double: 1
+idouble: 1
+ildouble: 1
+ldouble: 1
+
+Function: "exp2_downward":
+double: 1
+idouble: 1
+ildouble: 1
+ldouble: 1
+
+Function: "exp2_towardzero":
+double: 1
+idouble: 1
+ildouble: 1
+ldouble: 1
+
+Function: "exp2_upward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "exp_downward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+
+Function: "exp_towardzero":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+
+Function: "exp_upward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+
+Function: "expm1":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "expm1_downward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "expm1_towardzero":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 4
+ldouble: 4
+
+Function: "expm1_upward":
+double: 2
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 3
+ldouble: 3
+
+Function: "gamma":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 5
+ldouble: 5
+
+Function: "gamma_downward":
+double: 5
+float: 4
+idouble: 4
+ifloat: 4
+ildouble: 8
+ldouble: 8
+
+Function: "gamma_towardzero":
+double: 4
+float: 3
+idouble: 4
+ifloat: 3
+ildouble: 5
+ldouble: 5
+
+Function: "gamma_upward":
+double: 4
+float: 5
+idouble: 4
+ifloat: 5
+ildouble: 8
+ldouble: 8
+
+Function: "hypot":
+double: 1
+idouble: 1
+ildouble: 1
+ldouble: 1
+
+Function: "hypot_downward":
+double: 1
+idouble: 1
+ildouble: 1
+ldouble: 1
+
+Function: "hypot_towardzero":
+double: 1
+idouble: 1
+ildouble: 1
+ldouble: 1
+
+Function: "hypot_upward":
+double: 1
+idouble: 1
+ildouble: 1
+ldouble: 2
+
+Function: "j0":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: "j0_downward":
+double: 2
+float: 4
+idouble: 2
+ifloat: 4
+ildouble: 4
+ldouble: 4
+
+Function: "j0_towardzero":
+double: 2
+float: 1
+idouble: 3
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: "j0_upward":
+double: 3
+float: 2
+idouble: 3
+ifloat: 2
+ildouble: 5
+ldouble: 5
+
+Function: "j1":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 4
+ldouble: 4
+
+Function: "j1_downward":
+double: 3
+float: 2
+idouble: 3
+ifloat: 2
+ildouble: 4
+ldouble: 4
+
+Function: "j1_towardzero":
+double: 3
+float: 2
+idouble: 3
+ifloat: 2
+ildouble: 4
+ldouble: 4
+
+Function: "j1_upward":
+double: 3
+float: 4
+idouble: 3
+ifloat: 4
+ildouble: 3
+ldouble: 5
+
+Function: "jn":
+double: 4
+float: 4
+idouble: 4
+ifloat: 4
+ildouble: 7
+ldouble: 7
+
+Function: "jn_downward":
+double: 4
+float: 5
+idouble: 4
+ifloat: 5
+ildouble: 8
+ldouble: 8
+
+Function: "jn_towardzero":
+double: 4
+float: 5
+idouble: 4
+ifloat: 5
+ildouble: 8
+ldouble: 8
+
+Function: "jn_upward":
+double: 5
+float: 4
+idouble: 5
+ifloat: 4
+ildouble: 7
+ldouble: 7
+
+Function: "lgamma":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 5
+ldouble: 5
+
+Function: "lgamma_downward":
+double: 4
+float: 4
+idouble: 4
+ifloat: 4
+ildouble: 8
+ldouble: 8
+
+Function: "lgamma_towardzero":
+double: 4
+float: 4
+idouble: 4
+ifloat: 3
+ildouble: 5
+ldouble: 5
+
+Function: "lgamma_upward":
+double: 4
+float: 5
+idouble: 4
+ifloat: 5
+ildouble: 8
+ldouble: 8
+
+Function: "log":
+ildouble: 1
+ldouble: 1
+
+Function: "log10":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 1
+ldouble: 1
+
+Function: "log10_downward":
+double: 2
+float: 3
+idouble: 2
+ifloat: 3
+ildouble: 1
+ldouble: 1
+
+Function: "log10_towardzero":
+double: 2
+float: 1
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 1
+
+Function: "log10_upward":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 1
+
+Function: "log1p":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "log1p_downward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: "log1p_towardzero":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: "log1p_upward":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 4
+
+Function: "log2":
+float: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "log2_downward":
+ildouble: 3
+ldouble: 3
+
+Function: "log2_towardzero":
+double: 1
+idouble: 1
+ildouble: 3
+ldouble: 2
+
+Function: "log2_upward":
+double: 1
+idouble: 1
+ildouble: 3
+ldouble: 3
+
+Function: "log_downward":
+ildouble: 1
+ldouble: 1
+
+Function: "log_towardzero":
+ildouble: 2
+ldouble: 2
+
+Function: "log_upward":
+ildouble: 1
+ldouble: 1
+
+Function: "pow":
+double: 1
+idouble: 1
+ildouble: 2
+ldouble: 2
+
+Function: "pow_downward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "pow_towardzero":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "pow_upward":
+double: 2
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "sin":
+double: 1
+idouble: 1
+ildouble: 1
+ldouble: 1
+
+Function: "sin_downward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 3
+ldouble: 3
+
+Function: "sin_towardzero":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "sin_upward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 3
+ldouble: 3
+
+Function: "sincos":
+double: 1
+idouble: 1
+ildouble: 1
+ldouble: 1
+
+Function: "sincos_downward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 3
+ldouble: 3
+
+Function: "sincos_towardzero":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 2
+ldouble: 2
+
+Function: "sincos_upward":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 3
+ldouble: 3
+
+Function: "sinh":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: "sinh_downward":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 3
+ldouble: 3
+
+Function: "sinh_towardzero":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: "sinh_upward":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 4
+ldouble: 4
+
+Function: "tan":
+float: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "tan_downward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 2
+ildouble: 1
+ldouble: 1
+
+Function: "tan_towardzero":
+double: 1
+float: 1
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "tan_upward":
+double: 1
+float: 2
+idouble: 1
+ifloat: 1
+ildouble: 1
+ldouble: 1
+
+Function: "tanh":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: "tanh_downward":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 4
+ldouble: 4
+
+Function: "tanh_towardzero":
+double: 2
+float: 2
+idouble: 2
+ifloat: 2
+ildouble: 3
+ldouble: 3
+
+Function: "tanh_upward":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 3
+ldouble: 3
+
+Function: "tgamma":
+double: 5
+float: 4
+idouble: 5
+ifloat: 4
+ildouble: 4
+ldouble: 4
+
+Function: "tgamma_downward":
+double: 5
+float: 5
+idouble: 5
+ifloat: 5
+ildouble: 5
+ldouble: 5
+
+Function: "tgamma_towardzero":
+double: 5
+float: 4
+idouble: 5
+ifloat: 4
+ildouble: 5
+ldouble: 5
+
+Function: "tgamma_upward":
+double: 4
+float: 4
+idouble: 4
+ifloat: 4
+ildouble: 4
+ldouble: 4
+
+Function: "y0":
+double: 2
+float: 1
+idouble: 2
+ifloat: 1
+ildouble: 3
+ldouble: 3
+
+Function: "y0_downward":
+double: 3
+float: 4
+idouble: 3
+ifloat: 4
+ildouble: 4
+ldouble: 4
+
+Function: "y0_towardzero":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 3
+ldouble: 5
+
+Function: "y0_upward":
+double: 2
+float: 5
+idouble: 2
+ifloat: 5
+ildouble: 3
+ldouble: 5
+
+Function: "y1":
+double: 3
+float: 2
+idouble: 3
+ifloat: 2
+ildouble: 2
+ldouble: 2
+
+Function: "y1_downward":
+double: 3
+float: 2
+idouble: 3
+ifloat: 2
+ildouble: 4
+ldouble: 4
+
+Function: "y1_towardzero":
+double: 3
+float: 2
+idouble: 3
+ifloat: 2
+ildouble: 2
+ldouble: 5
+
+Function: "y1_upward":
+double: 5
+float: 2
+idouble: 5
+ifloat: 2
+ildouble: 5
+ldouble: 5
+
+Function: "yn":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 5
+ldouble: 5
+
+Function: "yn_downward":
+double: 3
+float: 4
+idouble: 3
+ifloat: 4
+ildouble: 5
+ldouble: 5
+
+Function: "yn_towardzero":
+double: 3
+float: 3
+idouble: 3
+ifloat: 3
+ildouble: 5
+ldouble: 5
+
+Function: "yn_upward":
+double: 4
+float: 5
+idouble: 4
+ifloat: 5
+ildouble: 5
+ldouble: 5
+
+# end of automatic generation
diff --git a/sysdeps/riscv/rv32/rvd/libm-test-ulps-name b/sysdeps/riscv/rv32/rvd/libm-test-ulps-name
new file mode 100644
index 0000000000..827fcdca19
--- /dev/null
+++ b/sysdeps/riscv/rv32/rvd/libm-test-ulps-name
@@ -0,0 +1 @@
+RISC-V
--
2.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* [RFC v6 18/23] RISC-V: Fix llrint and llround missing exceptions on RV32
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (16 preceding siblings ...)
2020-01-12 10:34 ` [RFC v6 17/23] RISC-V: Add the RV32 libm-test-ulps Alistair Francis
@ 2020-01-12 10:34 ` Alistair Francis
2020-01-12 10:34 ` [RFC v6 19/23] RISC-V: Build Infastructure for 32-bit Alistair Francis
` (5 subsequent siblings)
23 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:34 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
From: Zong Li <zongbox@gmail.com>
Similar to the 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.
---
.../riscv/rv32/fix-fp-int-convert-overflow.h | 38 +++++++++++++++++++
1 file changed, 38 insertions(+)
create mode 100644 sysdeps/riscv/rv32/fix-fp-int-convert-overflow.h
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..9137ee0fd8
--- /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. RISC-V version.
+ Copyright (C) 2015-2020 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
+
+/* 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.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* [RFC v6 19/23] RISC-V: Build Infastructure for 32-bit
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (17 preceding siblings ...)
2020-01-12 10:34 ` [RFC v6 18/23] RISC-V: Fix llrint and llround missing exceptions on RV32 Alistair Francis
@ 2020-01-12 10:34 ` Alistair Francis
2020-01-12 10:34 ` [RFC v6 20/23] riscv32: Specify the arch_minimum_kernel as 5.4 Alistair Francis
` (4 subsequent siblings)
23 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:34 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
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.
---
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 ++++-
9 files changed, 67 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/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 301b082398..6c11f7fd9a 100644
--- a/sysdeps/unix/sysv/linux/riscv/Makefile
+++ b/sysdeps/unix/sysv/linux/riscv/Makefile
@@ -7,11 +7,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..0f9552a1dd 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.31
+ld=ld-linux-riscv32-ilp32d.so.1
+%elif RISCV_ABI_XLEN == 32 && RISCV_ABI_FLEN == 0
+DEFAULT GLIBC_2.31
+ld=ld-linux-riscv32-ilp32.so.1
%else
%error cannot determine ABI
%endif
--
2.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* [RFC v6 20/23] riscv32: Specify the arch_minimum_kernel as 5.4
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (18 preceding siblings ...)
2020-01-12 10:34 ` [RFC v6 19/23] RISC-V: Build Infastructure for 32-bit Alistair Francis
@ 2020-01-12 10:34 ` Alistair Francis
2020-01-12 10:56 ` Andreas Schwab
2020-01-12 10:34 ` [RFC v6 21/23] RISC-V: Add rv32 path to RTLDLIST in ldd Alistair Francis
` (3 subsequent siblings)
23 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:34 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
---
sysdeps/unix/sysv/linux/riscv/configure | 1 +
sysdeps/unix/sysv/linux/riscv/configure.ac | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/sysdeps/unix/sysv/linux/riscv/configure b/sysdeps/unix/sysv/linux/riscv/configure
index 2b3c77f18c..db09edad1d 100755
--- a/sysdeps/unix/sysv/linux/riscv/configure
+++ b/sysdeps/unix/sysv/linux/riscv/configure
@@ -155,6 +155,7 @@ _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
+ arch_minimum_kernel=5.4.0
fi
rm -f conftest*
diff --git a/sysdeps/unix/sysv/linux/riscv/configure.ac b/sysdeps/unix/sysv/linux/riscv/configure.ac
index 710d46afcd..9c736415f7 100644
--- a/sysdeps/unix/sysv/linux/riscv/configure.ac
+++ b/sysdeps/unix/sysv/linux/riscv/configure.ac
@@ -13,6 +13,10 @@ if test $libc_cv_riscv_int_abi = no; then
AC_MSG_ERROR([Unable to determine integer ABI])
fi
+if test $libc_cv_riscv_int_abi = ilp32; then
+ arch_minimum_kernel=5.4.0
+fi
+
libc_cv_riscv_float_abi=no
AC_EGREP_CPP(yes, [#ifdef __riscv_float_abi_double
yes
--
2.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* Re: [RFC v6 20/23] riscv32: Specify the arch_minimum_kernel as 5.4
2020-01-12 10:34 ` [RFC v6 20/23] riscv32: Specify the arch_minimum_kernel as 5.4 Alistair Francis
@ 2020-01-12 10:56 ` Andreas Schwab
2020-01-14 7:25 ` Alistair Francis
0 siblings, 1 reply; 138+ messages in thread
From: Andreas Schwab @ 2020-01-12 10:56 UTC (permalink / raw)
To: Alistair Francis
Cc: libc-alpha, arnd, adhemerval.zanella, fweimer, joseph,
palmerdabbelt, macro, zongbox, alistair23
On Jan 12 2020, Alistair Francis wrote:
> diff --git a/sysdeps/unix/sysv/linux/riscv/configure b/sysdeps/unix/sysv/linux/riscv/configure
> index 2b3c77f18c..db09edad1d 100755
> --- a/sysdeps/unix/sysv/linux/riscv/configure
> +++ b/sysdeps/unix/sysv/linux/riscv/configure
> @@ -155,6 +155,7 @@ _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
> + arch_minimum_kernel=5.4.0
> fi
> rm -f conftest*
>
> diff --git a/sysdeps/unix/sysv/linux/riscv/configure.ac b/sysdeps/unix/sysv/linux/riscv/configure.ac
> index 710d46afcd..9c736415f7 100644
> --- a/sysdeps/unix/sysv/linux/riscv/configure.ac
> +++ b/sysdeps/unix/sysv/linux/riscv/configure.ac
> @@ -13,6 +13,10 @@ if test $libc_cv_riscv_int_abi = no; then
> AC_MSG_ERROR([Unable to determine integer ABI])
> fi
>
> +if test $libc_cv_riscv_int_abi = ilp32; then
> + arch_minimum_kernel=5.4.0
> +fi
> +
> libc_cv_riscv_float_abi=no
> AC_EGREP_CPP(yes, [#ifdef __riscv_float_abi_double
> yes
That doesn't fit together.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 20/23] riscv32: Specify the arch_minimum_kernel as 5.4
2020-01-12 10:56 ` Andreas Schwab
@ 2020-01-14 7:25 ` Alistair Francis
2020-01-14 9:03 ` Andreas Schwab
0 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-01-14 7:25 UTC (permalink / raw)
To: Andreas Schwab
Cc: Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Joseph Myers, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Sun, Jan 12, 2020 at 8:56 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> On Jan 12 2020, Alistair Francis wrote:
>
> > diff --git a/sysdeps/unix/sysv/linux/riscv/configure b/sysdeps/unix/sysv/linux/riscv/configure
> > index 2b3c77f18c..db09edad1d 100755
> > --- a/sysdeps/unix/sysv/linux/riscv/configure
> > +++ b/sysdeps/unix/sysv/linux/riscv/configure
> > @@ -155,6 +155,7 @@ _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
> > + arch_minimum_kernel=5.4.0
> > fi
> > rm -f conftest*
> >
> > diff --git a/sysdeps/unix/sysv/linux/riscv/configure.ac b/sysdeps/unix/sysv/linux/riscv/configure.ac
> > index 710d46afcd..9c736415f7 100644
> > --- a/sysdeps/unix/sysv/linux/riscv/configure.ac
> > +++ b/sysdeps/unix/sysv/linux/riscv/configure.ac
> > @@ -13,6 +13,10 @@ if test $libc_cv_riscv_int_abi = no; then
> > AC_MSG_ERROR([Unable to determine integer ABI])
> > fi
> >
> > +if test $libc_cv_riscv_int_abi = ilp32; then
> > + arch_minimum_kernel=5.4.0
> > +fi
> > +
> > libc_cv_riscv_float_abi=no
> > AC_EGREP_CPP(yes, [#ifdef __riscv_float_abi_double
> > yes
>
> That doesn't fit together.
I'm not clear what you mean. Which part?
Alistair
>
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 20/23] riscv32: Specify the arch_minimum_kernel as 5.4
2020-01-14 7:25 ` Alistair Francis
@ 2020-01-14 9:03 ` Andreas Schwab
0 siblings, 0 replies; 138+ messages in thread
From: Andreas Schwab @ 2020-01-14 9:03 UTC (permalink / raw)
To: Alistair Francis
Cc: Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Joseph Myers, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Jan 14 2020, Alistair Francis wrote:
> On Sun, Jan 12, 2020 at 8:56 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
>>
>> On Jan 12 2020, Alistair Francis wrote:
>>
>> > diff --git a/sysdeps/unix/sysv/linux/riscv/configure b/sysdeps/unix/sysv/linux/riscv/configure
>> > index 2b3c77f18c..db09edad1d 100755
>> > --- a/sysdeps/unix/sysv/linux/riscv/configure
>> > +++ b/sysdeps/unix/sysv/linux/riscv/configure
>> > @@ -155,6 +155,7 @@ _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
>> > + arch_minimum_kernel=5.4.0
>> > fi
>> > rm -f conftest*
>> >
>> > diff --git a/sysdeps/unix/sysv/linux/riscv/configure.ac b/sysdeps/unix/sysv/linux/riscv/configure.ac
>> > index 710d46afcd..9c736415f7 100644
>> > --- a/sysdeps/unix/sysv/linux/riscv/configure.ac
>> > +++ b/sysdeps/unix/sysv/linux/riscv/configure.ac
>> > @@ -13,6 +13,10 @@ if test $libc_cv_riscv_int_abi = no; then
>> > AC_MSG_ERROR([Unable to determine integer ABI])
>> > fi
>> >
>> > +if test $libc_cv_riscv_int_abi = ilp32; then
>> > + arch_minimum_kernel=5.4.0
>> > +fi
>> > +
>> > libc_cv_riscv_float_abi=no
>> > AC_EGREP_CPP(yes, [#ifdef __riscv_float_abi_double
>> > yes
>>
>> That doesn't fit together.
>
> I'm not clear what you mean. Which part?
Both parts.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 138+ messages in thread
* [RFC v6 21/23] RISC-V: Add rv32 path to RTLDLIST in ldd
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (19 preceding siblings ...)
2020-01-12 10:34 ` [RFC v6 20/23] riscv32: Specify the arch_minimum_kernel as 5.4 Alistair Francis
@ 2020-01-12 10:34 ` Alistair Francis
2020-01-12 10:34 ` [RFC v6 22/23] Documentation for the RISC-V 32-bit port Alistair Francis
` (2 subsequent siblings)
23 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:34 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
From: Zong Li <zong.li@sifive.com>
---
sysdeps/unix/sysv/linux/riscv/ldd-rewrite.sed | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sysdeps/unix/sysv/linux/riscv/ldd-rewrite.sed b/sysdeps/unix/sysv/linux/riscv/ldd-rewrite.sed
index 377a9c6ef4..bc0c4f51a1 100644
--- a/sysdeps/unix/sysv/linux/riscv/ldd-rewrite.sed
+++ b/sysdeps/unix/sysv/linux/riscv/ldd-rewrite.sed
@@ -1 +1 @@
-s_^\(RTLDLIST=\)\(.*lib/\)\(ld-linux\)-\(riscv64\)-\(lp64\)\(d*\)\(\.so\.[0-9.]*\)_\1"\2\3-\4-\5\7 \2\3-\4-\5d\7"_
+s_^\(RTLDLIST=\)\(.*lib\)\(/[^/]*\)\(64\|32\)\(-.*\)\(lp\)\(64\|32\)\(d*\)\(\.so\.[0-9.]*\)[ ]*$_\1"\2\364-\664\9 \2\364-\664\8\9 \2\332-i\632\9 \2\332-i\632\8\9"_
--
2.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* [RFC v6 22/23] Documentation for the RISC-V 32-bit port
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (20 preceding siblings ...)
2020-01-12 10:34 ` [RFC v6 21/23] RISC-V: Add rv32 path to RTLDLIST in ldd Alistair Francis
@ 2020-01-12 10:34 ` Alistair Francis
2020-01-12 10:34 ` [RFC v6 23/23] Add RISC-V 32-bit target to build-many-glibcs.py Alistair Francis
2020-01-12 14:44 ` [RFC v6 00/23] RISC-V glibc port for the 32-bit Joseph Myers
23 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:34 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
From: Zong Li <zongbox@gmail.com>
There is already RISC-V 64-bit port information in the documentation.
Let's add some documentation entries for the RISC-V 32-bit as well.
---
NEWS | 6 ++++++
README | 1 +
2 files changed, 7 insertions(+)
diff --git a/NEWS b/NEWS
index 44065d936a..d124a859da 100644
--- a/NEWS
+++ b/NEWS
@@ -36,6 +36,12 @@ Major new features:
responses, indicating a lack of DNSSEC validation. (Therefore, the name
servers and the network path to them are treated as untrusted.)
+* 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 totalorder and totalordermag functions, and the corresponding
diff --git a/README b/README
index 31c5da0405..cee86ab178 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.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* [RFC v6 23/23] Add RISC-V 32-bit target to build-many-glibcs.py
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (21 preceding siblings ...)
2020-01-12 10:34 ` [RFC v6 22/23] Documentation for the RISC-V 32-bit port Alistair Francis
@ 2020-01-12 10:34 ` Alistair Francis
2020-01-12 14:44 ` [RFC v6 00/23] RISC-V glibc port for the 32-bit Joseph Myers
23 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-12 10:34 UTC (permalink / raw)
To: libc-alpha
Cc: arnd, adhemerval.zanella, fweimer, joseph, palmerdabbelt, macro,
zongbox, alistair.francis, alistair23
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
---
scripts/build-many-glibcs.py | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/scripts/build-many-glibcs.py b/scripts/build-many-glibcs.py
index 1bd7f24d7d..66f6188cf2 100755
--- a/scripts/build-many-glibcs.py
+++ b/scripts/build-many-glibcs.py
@@ -331,6 +331,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.24.1
^ permalink raw reply related [flat|nested] 138+ messages in thread* Re: [RFC v6 00/23] RISC-V glibc port for the 32-bit
2020-01-12 10:33 [RFC v6 00/23] RISC-V glibc port for the 32-bit Alistair Francis
` (22 preceding siblings ...)
2020-01-12 10:34 ` [RFC v6 23/23] Add RISC-V 32-bit target to build-many-glibcs.py Alistair Francis
@ 2020-01-12 14:44 ` Joseph Myers
2020-01-14 7:30 ` Alistair Francis
23 siblings, 1 reply; 138+ messages in thread
From: Joseph Myers @ 2020-01-12 14:44 UTC (permalink / raw)
To: Alistair Francis
Cc: libc-alpha, arnd, adhemerval.zanella, fweimer, palmerdabbelt,
macro, zongbox, alistair23
On Sun, 12 Jan 2020, Alistair Francis wrote:
> This is a list of the tests that are currently failing when running make
> check:
Could you give more details for the FAILing tests of why they are failing?
> FAIL: conform/ISO11/stdalign.h/conform
> FAIL: conform/POSIX/sys/mman.h/conform
No ports should be added where any compilation tests are failing. You
need to fix all the compilation tests so that build-many-glibcs.py results
can remain clean.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 00/23] RISC-V glibc port for the 32-bit
2020-01-12 14:44 ` [RFC v6 00/23] RISC-V glibc port for the 32-bit Joseph Myers
@ 2020-01-14 7:30 ` Alistair Francis
2020-01-14 22:08 ` Joseph Myers
0 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-01-14 7:30 UTC (permalink / raw)
To: Joseph Myers
Cc: Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Mon, Jan 13, 2020 at 12:44 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Sun, 12 Jan 2020, Alistair Francis wrote:
>
> > This is a list of the tests that are currently failing when running make
> > check:
>
> Could you give more details for the FAILing tests of why they are failing?
>
> > FAIL: conform/ISO11/stdalign.h/conform
> > FAIL: conform/POSIX/sys/mman.h/conform
>
> No ports should be added where any compilation tests are failing. You
> need to fix all the compilation tests so that build-many-glibcs.py results
> can remain clean.
Yep.
The errors I get are strange though, I'm not sure how to debug:
# cat conform/ISO11/stdalign.h/conform.out
Traceback (most recent call last):
File "conformtest.py", line 26, in <module>
import tempfile
File "/usr/lib/python3.7/tempfile.py", line 45, in <module>
from random import Random as _Random
File "/usr/lib/python3.7/random.py", line 58, in <module>
NV_MAGICCONST = 4 * _exp(-0.5)/_sqrt(2.0)
ValueError: math domain error
# cat conform/POSIX/sys/mman.h/conform.out
Traceback (most recent call last):
File "conformtest.py", line 26, in <module>
import tempfile
File "/usr/lib/python3.7/tempfile.py", line 45, in <module>
from random import Random as _Random
File "/usr/lib/python3.7/random.py", line 58, in <module>
NV_MAGICCONST = 4 * _exp(-0.5)/_sqrt(2.0)
ZeroDivisionError: float division by zero
Alistair
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 00/23] RISC-V glibc port for the 32-bit
2020-01-14 7:30 ` Alistair Francis
@ 2020-01-14 22:08 ` Joseph Myers
2020-01-15 4:30 ` Alistair Francis
0 siblings, 1 reply; 138+ messages in thread
From: Joseph Myers @ 2020-01-14 22:08 UTC (permalink / raw)
To: Alistair Francis
Cc: Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Tue, 14 Jan 2020, Alistair Francis wrote:
> Yep.
>
> The errors I get are strange though, I'm not sure how to debug:
>
> # cat conform/ISO11/stdalign.h/conform.out
> Traceback (most recent call last):
> File "conformtest.py", line 26, in <module>
> import tempfile
> File "/usr/lib/python3.7/tempfile.py", line 45, in <module>
> from random import Random as _Random
> File "/usr/lib/python3.7/random.py", line 58, in <module>
> NV_MAGICCONST = 4 * _exp(-0.5)/_sqrt(2.0)
> ValueError: math domain error
That suggests you've got a broken python installation. If you're doing
native testing on RV32, I suggest doing cross-testing (using
cross-test-ssh.sh) instead, so that python runs on a known-good build
system, until the RV32 system is stable enough.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 00/23] RISC-V glibc port for the 32-bit
2020-01-14 22:08 ` Joseph Myers
@ 2020-01-15 4:30 ` Alistair Francis
2020-01-15 21:50 ` Joseph Myers
0 siblings, 1 reply; 138+ messages in thread
From: Alistair Francis @ 2020-01-15 4:30 UTC (permalink / raw)
To: Joseph Myers
Cc: Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Wed, Jan 15, 2020 at 8:08 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Tue, 14 Jan 2020, Alistair Francis wrote:
>
> > Yep.
> >
> > The errors I get are strange though, I'm not sure how to debug:
> >
> > # cat conform/ISO11/stdalign.h/conform.out
> > Traceback (most recent call last):
> > File "conformtest.py", line 26, in <module>
> > import tempfile
> > File "/usr/lib/python3.7/tempfile.py", line 45, in <module>
> > from random import Random as _Random
> > File "/usr/lib/python3.7/random.py", line 58, in <module>
> > NV_MAGICCONST = 4 * _exp(-0.5)/_sqrt(2.0)
> > ValueError: math domain error
>
> That suggests you've got a broken python installation. If you're doing
> native testing on RV32, I suggest doing cross-testing (using
> cross-test-ssh.sh) instead, so that python runs on a known-good build
> system, until the RV32 system is stable enough.
Thanks for the tip!
When running on my x86_64 machine and using this command to run the
tests on RV32:
make test-wrapper='/slow-scratch/alistair/software/glibc/scripts/cross-test-ssh.sh
--ssh "ssh -p 2222" --timeoutfactor 100 root@127.0.0.1' tests
I get this result:
FAIL: elf/check-abi-libc
Summary of test results:
1 FAIL
1204 PASS
15 XFAIL
The failure for elf/check-abi-libc.out is:
--- ../sysdeps/unix/sysv/linux/riscv/libc.abilist 2020-01-14
16:27:58.805195715 -0800
+++ /slow-scratch/alistair/software/glibc/build/libc.symlist
2020-01-14 18:48:08.711608082 -0800
@@ -510 +510 @@ GLIBC_2.31 _mcount F
-GLIBC_2.31 _nl_default_dirname D 0x12
+GLIBC_2.31 _nl_default_dirname D 0x16
I have tried making this change before, but then the test case fails
when running ./scripts/build-many-glibcs.py
Any ideas why there are conflicting values for _nl_default_dirname and
which one should it be?
Also, as it seems like all the conform tests are passing when run via
cross compile can I assume the failure is related to Python and mark
it as passing?
Alistair
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [RFC v6 00/23] RISC-V glibc port for the 32-bit
2020-01-15 4:30 ` Alistair Francis
@ 2020-01-15 21:50 ` Joseph Myers
2020-01-15 23:50 ` Alistair Francis
0 siblings, 1 reply; 138+ messages in thread
From: Joseph Myers @ 2020-01-15 21:50 UTC (permalink / raw)
To: Alistair Francis
Cc: Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Wed, 15 Jan 2020, Alistair Francis wrote:
> --- ../sysdeps/unix/sysv/linux/riscv/libc.abilist 2020-01-14
> 16:27:58.805195715 -0800
> +++ /slow-scratch/alistair/software/glibc/build/libc.symlist
> 2020-01-14 18:48:08.711608082 -0800
> @@ -510 +510 @@ GLIBC_2.31 _mcount F
> -GLIBC_2.31 _nl_default_dirname D 0x12
> +GLIBC_2.31 _nl_default_dirname D 0x16
You need to use --prefix=/usr; the length of the prefix affect the ABI.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [RFC v6 00/23] RISC-V glibc port for the 32-bit
2020-01-15 21:50 ` Joseph Myers
@ 2020-01-15 23:50 ` Alistair Francis
0 siblings, 0 replies; 138+ messages in thread
From: Alistair Francis @ 2020-01-15 23:50 UTC (permalink / raw)
To: Joseph Myers
Cc: Alistair Francis, GNU C Library, Arnd Bergmann,
Adhemerval Zanella, Florian Weimer, Palmer Dabbelt,
Maciej W. Rozycki, Zong Li
On Thu, Jan 16, 2020 at 7:50 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Wed, 15 Jan 2020, Alistair Francis wrote:
>
> > --- ../sysdeps/unix/sysv/linux/riscv/libc.abilist 2020-01-14
> > 16:27:58.805195715 -0800
> > +++ /slow-scratch/alistair/software/glibc/build/libc.symlist
> > 2020-01-14 18:48:08.711608082 -0800
> > @@ -510 +510 @@ GLIBC_2.31 _mcount F
> > -GLIBC_2.31 _nl_default_dirname D 0x12
> > +GLIBC_2.31 _nl_default_dirname D 0x16
>
> You need to use --prefix=/usr; the length of the prefix affect the ABI.
Ah, thanks.
So it looks like all the conform tests are passing :)
I'm running the full suit of tests via cross compiling with NFS mount
as well. When the 2.32 window opens up I should be ready to go.
Thanks for all of your help Joseph.
Alistair
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
^ permalink raw reply [flat|nested] 138+ messages in thread