Re: [PATCH v2 1/2] RISC-V: remove riscv-specific sigcontext.h

[Palmer Dabbelt <palmer@dabbelt.com>]

On Mon, 17 Jan 2022 20:31:58 PST (-0800), vincent.chen@sifive.com wrote:
> Remove riscv-specific sigcontext.h so that Glibc can directly use
> sigcontext.h provided by the kernel to reduce synchronization work
> when new extension support is introduced.
> ---
>  .../unix/sysv/linux/riscv/bits/sigcontext.h   | 31 -------------------
>  1 file changed, 31 deletions(-)
>  delete mode 100644 sysdeps/unix/sysv/linux/riscv/bits/sigcontext.h
>
> diff --git a/sysdeps/unix/sysv/linux/riscv/bits/sigcontext.h b/sysdeps/unix/sysv/linux/riscv/bits/sigcontext.h
> deleted file mode 100644
> index b6e15b5f62..0000000000
> --- a/sysdeps/unix/sysv/linux/riscv/bits/sigcontext.h
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -/* Machine-dependent signal context structure for Linux.  RISC-V version.
> -   Copyright (C) 1996-2022 Free Software Foundation, Inc.  This file is part of the GNU C Library.
> -
> -   The GNU C Library is free software; you can redistribute it and/or
> -   modify it under the terms of the GNU Lesser General Public
> -   License as published by the Free Software Foundation; either
> -   version 2.1 of the License, or (at your option) any later version.
> -
> -   The GNU C Library is distributed in the hope that it will be useful,
> -   but WITHOUT ANY WARRANTY; without even the implied warranty of
> -   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> -   Lesser General Public License for more details.
> -
> -   You should have received a copy of the GNU Lesser General Public
> -   License along with the GNU C Library.  If not, see
> -   <https://www.gnu.org/licenses/>.  */
> -
> -#ifndef _BITS_SIGCONTEXT_H
> -#define _BITS_SIGCONTEXT_H 1
> -
> -#if !defined _SIGNAL_H && !defined _SYS_UCONTEXT_H
> -# error "Never use <bits/sigcontext.h> directly; include <signal.h> instead."
> -#endif
> -
> -struct sigcontext {
> -  /* gregs[0] holds the program counter.  */
> -  unsigned long int gregs[32];
> -  unsigned long long int fpregs[66] __attribute__ ((__aligned__ (16)));
> -};
> -
> -#endif

This will definitely break API compatibility (the fields have 
different names) but should be fine for ABI compatibility.  IIUC that's 
within the rules, but I'm not sure it's a desirable outcome.  Probably 
would have been better to get this right the first time around, but I'm 
not sure it's worth fixing -- essentially we're making a bunch of users 
change things so we don't have to.  That said, it's pretty ugly to have 
two different definitions of a structure with the same name and layout.

Maybe there's some sort of macro-related trick we can use?  ie, provide 
the current definition unless users opt into the Linux one (presumably 
so they can talk about the V state).  There's going to be some hoops to 
jump through there to maintain ABI compatibility either way, so it's 
possible we could tie these two together?