linux-snps-arc.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
       [not found] ` <4e95f95966d8d7c6a8339160dc62d81c1f6a1bfb.1578824547.git.alistair.francis@wdc.com>
@ 2020-02-12  0:14   ` Vineet Gupta
  2020-02-12  0:14     ` Alistair Francis
  2020-02-19  0:56   ` Vineet Gupta
  1 sibling, 1 reply; 62+ messages in thread
From: Vineet Gupta @ 2020-02-12  0:14 UTC (permalink / raw)
  To: Alistair Francis, libc-alpha
  Cc: fweimer, arnd, palmerdabbelt, zongbox, adhemerval.zanella, macro,
	alistair23, arcml, joseph

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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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   ` [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64 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; 62+ messages in thread
From: Alistair Francis @ 2020-02-12  0:14 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: Florian Weimer, GNU C Library, Arnd Bergmann, Palmer Dabbelt,
	Zong Li, Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
	arcml, Joseph Myers

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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Joseph Myers @ 2020-02-12  1:30 UTC (permalink / raw)
  To: Alistair Francis
  Cc: Florian Weimer, GNU C Library, Arnd Bergmann, Vineet Gupta,
	Palmer Dabbelt, Zong Li, Alistair Francis, Adhemerval Zanella,
	Maciej W. Rozycki, 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Arnd Bergmann @ 2020-02-12 12:58 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: Florian Weimer, GNU C Library, Palmer Dabbelt, Zong Li,
	Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
	Alistair Francis, 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Alistair Francis @ 2020-02-14 22:39 UTC (permalink / raw)
  To: Joseph Myers
  Cc: Florian Weimer, GNU C Library, Arnd Bergmann, Vineet Gupta,
	Palmer Dabbelt, Zong Li, Alistair Francis, Adhemerval Zanella,
	Maciej W. Rozycki, 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ 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



_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Joseph Myers @ 2020-02-18 23:13 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: Florian Weimer, GNU C Library, Arnd Bergmann, Palmer Dabbelt,
	Zong Li, Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
	Alistair Francis, 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
       [not found] ` <4e95f95966d8d7c6a8339160dc62d81c1f6a1bfb.1578824547.git.alistair.francis@wdc.com>
  2020-02-12  0:14   ` [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64 Vineet Gupta
@ 2020-02-19  0:56   ` Vineet Gupta
  2020-02-19  1:03     ` Alistair Francis
  1 sibling, 1 reply; 62+ messages in thread
From: Vineet Gupta @ 2020-02-19  0:56 UTC (permalink / raw)
  To: Alistair Francis, libc-alpha
  Cc: fweimer, arnd, palmerdabbelt, zongbox, adhemerval.zanella, macro,
	alistair23, arcml, joseph

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
> 

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Alistair Francis @ 2020-02-19  1:03 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: fweimer, libc-alpha, arnd, palmerdabbelt, zongbox,
	Alistair Francis, adhemerval.zanella, macro, arcml, joseph

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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Vineet Gupta @ 2020-02-19  1:31 UTC (permalink / raw)
  To: Alistair Francis
  Cc: fweimer, libc-alpha, arnd, palmerdabbelt, zongbox,
	Alistair Francis, adhemerval.zanella, macro, arcml, joseph

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
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Andreas Schwab @ 2020-02-19  8:30 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: fweimer, libc-alpha, arnd, palmerdabbelt, zongbox,
	Alistair Francis, adhemerval.zanella, macro, Alistair Francis,
	arcml, joseph

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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Vineet Gupta @ 2020-02-19 18:42 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: fweimer, libc-alpha, arnd, palmerdabbelt, zongbox,
	Alistair Francis, adhemerval.zanella, macro, Alistair Francis,
	arcml, joseph

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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Lukasz Majewski @ 2020-02-19 23:09 UTC (permalink / raw)
  To: Joseph Myers, Vineet Gupta
  Cc: Florian Weimer, GNU C Library, Arnd Bergmann, Palmer Dabbelt,
	Zong Li, Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
	Alistair Francis, arcml


[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Lukasz Majewski @ 2020-02-19 23:11 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: Florian Weimer, GNU C Library, Arnd Bergmann, Palmer Dabbelt,
	Zong Li, Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
	Alistair Francis, arcml, Joseph Myers


[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Lukasz Majewski @ 2020-02-19 23:18 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: fweimer, libc-alpha, arnd, Andreas Schwab, palmerdabbelt,
	zongbox, Alistair Francis, adhemerval.zanella, macro,
	Alistair Francis, arcml, joseph


[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Vineet Gupta @ 2020-02-20  0:26 UTC (permalink / raw)
  To: Lukasz Majewski
  Cc: fweimer, libc-alpha, arnd, Andreas Schwab, palmerdabbelt,
	zongbox, Alistair Francis, adhemerval.zanella, macro,
	Alistair Francis, arcml, joseph

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



_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Joseph Myers @ 2020-02-20  0:46 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: fweimer, libc-alpha, arnd, Andreas Schwab, palmerdabbelt,
	Lukasz Majewski, zongbox, Alistair Francis, adhemerval.zanella,
	macro, 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Arnd Bergmann @ 2020-02-20  8:24 UTC (permalink / raw)
  To: Joseph Myers
  Cc: fweimer, libc-alpha, Andreas Schwab, Vineet Gupta, palmerdabbelt,
	Lukasz Majewski, zongbox, Alistair Francis, adhemerval.zanella,
	macro, 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Arnd Bergmann @ 2020-02-20  8:31 UTC (permalink / raw)
  To: Lukasz Majewski
  Cc: 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 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Lukasz Majewski @ 2020-02-20  9:37 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: 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.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Lukasz Majewski @ 2020-02-20 10:28 UTC (permalink / raw)
  To: Arnd Bergmann, Joseph Myers
  Cc: fweimer, libc-alpha, Andreas Schwab, Vineet Gupta, palmerdabbelt,
	zongbox, Alistair Francis, adhemerval.zanella, macro,
	Alistair Francis, arcml


[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Arnd Bergmann @ 2020-02-20 12:37 UTC (permalink / raw)
  To: Lukasz Majewski
  Cc: 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 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Lukasz Majewski @ 2020-02-20 13:14 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: 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.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Joseph Myers @ 2020-02-20 14:14 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: fweimer, libc-alpha, Andreas Schwab, Vineet Gupta, palmerdabbelt,
	Lukasz Majewski, zongbox, Alistair Francis, adhemerval.zanella,
	macro, 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Arnd Bergmann @ 2020-02-20 14:44 UTC (permalink / raw)
  To: Lukasz Majewski
  Cc: Florian Weimer, Helmut Grohne, GNU C Library, Viresh Kumar,
	Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
	Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
	Alistair Francis, arcml, Joseph Myers

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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Lukasz Majewski @ 2020-02-20 15:42 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Florian Weimer, Helmut Grohne, GNU C Library, Viresh Kumar,
	Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
	Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
	Alistair Francis, arcml, Joseph Myers


[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Arnd Bergmann @ 2020-02-20 16:08 UTC (permalink / raw)
  To: Lukasz Majewski
  Cc: Florian Weimer, Helmut Grohne, GNU C Library, Viresh Kumar,
	Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
	Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
	Alistair Francis, arcml, Joseph Myers

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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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
  1 sibling, 1 reply; 62+ messages in thread
From: Helmut Grohne @ 2020-02-20 16:27 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Florian Weimer, GNU C Library, Vineet Gupta, Palmer Dabbelt,
	Lukasz Majewski, Zong Li, debian-arm, Alistair Francis,
	Adhemerval Zanella, Maciej W. Rozycki, Alistair Francis, arcml,
	Joseph Myers

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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Lukasz Majewski @ 2020-02-20 16:31 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Florian Weimer, Helmut Grohne, GNU C Library, Viresh Kumar,
	Vineet Gupta, Palmer Dabbelt, Zong Li, debian-arm,
	Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
	Alistair Francis, arcml, Joseph Myers


[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Alistair Francis @ 2020-02-21 19:56 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Florian Weimer, Helmut Grohne, GNU C Library, Vineet Gupta,
	Palmer Dabbelt, Lukasz Majewski, Zong Li, debian-arm,
	Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki, arcml,
	Joseph Myers

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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Arnd Bergmann @ 2020-02-22  8:42 UTC (permalink / raw)
  To: Lukasz Majewski
  Cc: 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 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Viresh Kumar @ 2020-02-24  2:48 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Florian Weimer, Helmut Grohne, GNU C Library, Viresh Kumar,
	Vineet Gupta, Palmer Dabbelt, Lukasz Majewski, Zong Li,
	debian-arm, Alistair Francis, Adhemerval Zanella,
	Maciej W. Rozycki, Alistair Francis, arcml, Joseph Myers

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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Lukasz Majewski @ 2020-02-24  9:00 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: 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.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Andreas Schwab @ 2020-02-24  9:46 UTC (permalink / raw)
  To: Lukasz Majewski
  Cc: Florian Weimer, Palmer Dabbelt, GNU C Library, Arnd Bergmann,
	Vineet Gupta, Helmut Grohne, 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."

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Lukasz Majewski @ 2020-02-24 10:14 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: Florian Weimer, Palmer Dabbelt, GNU C Library, Arnd Bergmann,
	Vineet Gupta, Helmut Grohne, Zong Li, debian-arm,
	Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
	Alistair Francis, arcml, Joseph Myers


[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Andreas Schwab @ 2020-02-24 10:23 UTC (permalink / raw)
  To: Lukasz Majewski
  Cc: Florian Weimer, Palmer Dabbelt, GNU C Library, Arnd Bergmann,
	Vineet Gupta, Helmut Grohne, 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."

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Lukasz Majewski @ 2020-02-24 10:36 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: Florian Weimer, Palmer Dabbelt, GNU C Library, Arnd Bergmann,
	Vineet Gupta, Helmut Grohne, Zong Li, debian-arm,
	Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
	Alistair Francis, arcml, Joseph Myers


[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Andreas Schwab @ 2020-02-24 10:42 UTC (permalink / raw)
  To: Lukasz Majewski
  Cc: Florian Weimer, Palmer Dabbelt, GNU C Library, Arnd Bergmann,
	Vineet Gupta, Helmut Grohne, 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."

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Lukasz Majewski @ 2020-02-24 11:13 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: Florian Weimer, Palmer Dabbelt, GNU C Library, Arnd Bergmann,
	Vineet Gupta, Helmut Grohne, Zong Li, debian-arm,
	Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
	Alistair Francis, arcml, Joseph Myers


[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Lukasz Majewski @ 2020-02-24 12:41 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: Florian Weimer, Palmer Dabbelt, GNU C Library, Arnd Bergmann,
	Vineet Gupta, Helmut Grohne, Zong Li, debian-arm,
	Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
	Alistair Francis, arcml, Joseph Myers


[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Joseph Myers @ 2020-02-25  0:03 UTC (permalink / raw)
  To: Lukasz Majewski
  Cc: Florian Weimer, Palmer Dabbelt, GNU C Library, Arnd Bergmann,
	Andreas Schwab, Vineet Gupta, Helmut Grohne, 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Arnd Bergmann @ 2020-02-25  9:03 UTC (permalink / raw)
  To: Lukasz Majewski
  Cc: 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 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Lukasz Majewski @ 2020-02-25 11:39 UTC (permalink / raw)
  To: Joseph Myers
  Cc: Florian Weimer, Palmer Dabbelt, GNU C Library, Arnd Bergmann,
	Andreas Schwab, Vineet Gupta, Helmut Grohne, Zong Li, debian-arm,
	Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
	Alistair Francis, arcml


[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Joseph Myers @ 2020-02-25 14:36 UTC (permalink / raw)
  To: Lukasz Majewski
  Cc: Florian Weimer, Palmer Dabbelt, GNU C Library, Arnd Bergmann,
	Andreas Schwab, Vineet Gupta, Helmut Grohne, 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Lukasz Majewski @ 2020-02-26 13:18 UTC (permalink / raw)
  To: Joseph Myers
  Cc: Florian Weimer, Palmer Dabbelt, GNU C Library, Arnd Bergmann,
	Andreas Schwab, Vineet Gupta, Helmut Grohne, Zong Li, debian-arm,
	Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
	Alistair Francis, arcml


[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Joseph Myers @ 2020-02-26 14:48 UTC (permalink / raw)
  To: Lukasz Majewski
  Cc: Florian Weimer, Palmer Dabbelt, GNU C Library, Arnd Bergmann,
	Andreas Schwab, Vineet Gupta, Helmut Grohne, 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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; 62+ messages in thread
From: Lukasz Majewski @ 2020-02-26 16:28 UTC (permalink / raw)
  To: Joseph Myers
  Cc: Florian Weimer, Palmer Dabbelt, GNU C Library, Arnd Bergmann,
	Andreas Schwab, Vineet Gupta, Helmut Grohne, Zong Li, debian-arm,
	Alistair Francis, Adhemerval Zanella, Maciej W. Rozycki,
	Alistair Francis, arcml


[-- Attachment #1.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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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
  2020-03-26  5:54                     ` Helmut Grohne
  0 siblings, 1 reply; 62+ messages in thread
From: Vineet Gupta @ 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


_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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
@ 2020-03-26  5:54                     ` Helmut Grohne
  2020-03-26 11:51                       ` Alexey Brodkin
  2020-08-26 14:39                       ` Vineet Gupta
  0 siblings, 2 replies; 62+ 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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
  2020-03-26 12:24                         ` Helmut Grohne
  2020-08-26 14:39                       ` Vineet Gupta
  1 sibling, 1 reply; 62+ messages in thread
From: Alexey Brodkin @ 2020-03-26 11:51 UTC (permalink / raw)
  To: Helmut Grohne; +Cc: debian-arm, 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
  2020-03-26 11:51                       ` Alexey Brodkin
@ 2020-03-26 12:24                         ` Helmut Grohne
  2020-03-26 12:53                           ` Alexey Brodkin
  0 siblings, 1 reply; 62+ messages in thread
From: Helmut Grohne @ 2020-03-26 12:24 UTC (permalink / raw)
  To: Alexey Brodkin; +Cc: debian-arm, 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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
  2020-03-26 14:28                             ` Helmut Grohne
  0 siblings, 1 reply; 62+ messages in thread
From: Alexey Brodkin @ 2020-03-26 12:53 UTC (permalink / raw)
  To: Helmut Grohne
  Cc: GNU C Library, Vineet Gupta, Vineet Gupta, debian-arm, 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
  2020-03-26 12:53                           ` Alexey Brodkin
@ 2020-03-26 14:28                             ` Helmut Grohne
  2020-03-26 19:04                               ` Lennart Sorensen
  0 siblings, 1 reply; 62+ 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, 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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
  0 siblings, 0 replies; 62+ messages in thread
From: Lennart Sorensen @ 2020-03-26 19:04 UTC (permalink / raw)
  To: Helmut Grohne, Alexey Brodkin, debian-arm, 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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
@ 2020-08-26 14:39                       ` Vineet Gupta
  2020-08-26 15:43                         ` Helmut Grohne
  1 sibling, 1 reply; 62+ messages in thread
From: Vineet Gupta @ 2020-08-26 14:39 UTC (permalink / raw)
  To: debian-cross; +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
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
  2020-08-26 14:39                       ` Vineet Gupta
@ 2020-08-26 15:43                         ` Helmut Grohne
  2020-08-26 21:16                           ` Aurelien Jarno
  0 siblings, 1 reply; 62+ messages in thread
From: Helmut Grohne @ 2020-08-26 15:43 UTC (permalink / raw)
  To: Vineet Gupta; +Cc: debian-glibc, debian-cross, 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


_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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
  2021-08-21 17:36                             ` Aurelien Jarno
  0 siblings, 2 replies; 62+ messages in thread
From: Aurelien Jarno @ 2020-08-26 21:16 UTC (permalink / raw)
  To: Vineet Gupta, debian-cross, 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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
  2021-02-26  9:47                               ` Helmut Grohne
  2021-08-21 17:36                             ` Aurelien Jarno
  1 sibling, 1 reply; 62+ messages in thread
From: Vineet Gupta @ 2021-02-24 20:17 UTC (permalink / raw)
  To: Vineet Gupta, debian-cross, GNU C Library, arcml, debian-glibc,
	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
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ messages in thread

* Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
  2021-02-24 20:17                             ` Vineet Gupta
@ 2021-02-26  9:47                               ` Helmut Grohne
  2021-02-26 15:58                                 ` Vineet Gupta
  0 siblings, 1 reply; 62+ messages in thread
From: Helmut Grohne @ 2021-02-26  9:47 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: debian-glibc, debian-cross, 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


_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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
  0 siblings, 0 replies; 62+ messages in thread
From: Vineet Gupta @ 2021-02-26 15:58 UTC (permalink / raw)
  To: debian-cross, GNU C Library, arcml, debian-glibc, 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


_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ 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
@ 2021-08-21 17:36                             ` Aurelien Jarno
  1 sibling, 0 replies; 62+ messages in thread
From: Aurelien Jarno @ 2021-08-21 17:36 UTC (permalink / raw)
  To: Vineet Gupta, debian-cross, 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

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 62+ messages in thread

end of thread, other threads:[~2021-08-21 17:36 UTC | newest]

Thread overview: 62+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <cover.1578824547.git.alistair.francis@wdc.com>
     [not found] ` <4e95f95966d8d7c6a8339160dc62d81c1f6a1bfb.1578824547.git.alistair.francis@wdc.com>
2020-02-12  0:14   ` [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64 Vineet Gupta
2020-02-12  0:14     ` Alistair Francis
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
2020-02-18 23:13             ` Joseph Myers
2020-02-19 23:09               ` Lukasz Majewski
2020-02-19 23:11             ` Lukasz Majewski
2020-02-20  8:31               ` Arnd Bergmann
2020-02-20  9:37                 ` Lukasz Majewski
2020-02-20 12:37                   ` Arnd Bergmann
2020-02-20 13:14                     ` Lukasz Majewski
2020-02-20 14:44                       ` Arnd Bergmann
2020-02-20 15:42                         ` Lukasz Majewski
2020-02-20 16:08                           ` Arnd Bergmann
2020-02-20 16:31                             ` Lukasz Majewski
2020-02-24  2:48                         ` Viresh Kumar
2020-02-21 19:56                     ` Alistair Francis
2020-02-22  8:42                   ` Arnd Bergmann
2020-02-24  9:00                     ` Lukasz Majewski
2020-02-24  9:46                       ` Andreas Schwab
2020-02-24 10:14                         ` Lukasz Majewski
2020-02-24 10:23                           ` Andreas Schwab
2020-02-24 10:36                             ` Lukasz Majewski
2020-02-24 10:42                               ` Andreas Schwab
2020-02-24 11:13                                 ` Lukasz Majewski
2020-02-24 12:41                                   ` Lukasz Majewski
2020-02-25  0:03                               ` Joseph Myers
2020-02-25 11:39                                 ` Lukasz Majewski
2020-02-25 14:36                                   ` Joseph Myers
2020-02-26 13:18                                     ` Lukasz Majewski
2020-02-26 14:48                                       ` Joseph Myers
2020-02-26 16:28                                         ` Lukasz Majewski
2020-02-25  9:03                       ` Arnd Bergmann
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
2020-03-26  5:54                     ` Helmut Grohne
2020-03-26 11:51                       ` Alexey Brodkin
2020-03-26 12:24                         ` Helmut Grohne
2020-03-26 12:53                           ` Alexey Brodkin
2020-03-26 14:28                             ` Helmut Grohne
2020-03-26 19:04                               ` Lennart Sorensen
2020-08-26 14:39                       ` Vineet Gupta
2020-08-26 15:43                         ` Helmut Grohne
2020-08-26 21:16                           ` Aurelien Jarno
2021-02-24 20:17                             ` Vineet Gupta
2021-02-26  9:47                               ` Helmut Grohne
2021-02-26 15:58                                 ` Vineet Gupta
2021-08-21 17:36                             ` Aurelien Jarno
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
2020-02-19  0:56   ` Vineet Gupta
2020-02-19  1:03     ` Alistair Francis
2020-02-19  1:31       ` Vineet Gupta
2020-02-19  8:30         ` Andreas Schwab
2020-02-19 18:42           ` Vineet Gupta
2020-02-19 23:18             ` Lukasz Majewski
2020-02-20  0:26               ` Vineet Gupta
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

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