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

[Kito Cheng <kito.cheng@sifive.com>]

Just provide a tricky workaround from GCC side:

+#ifdef _ASM_RISCV_SIGCONTEXT_H
+#define SIGCONTEXT_PC(SC) (SC)->sc_regs.pc
+#else
+#define SIGCONTEXT_PC(SC) (SC)->gregs[0]
+#endif

https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588682.html


On Thu, Jan 20, 2022 at 10:36 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> 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?