From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by sourceware.org (Postfix) with ESMTPS id 8EE13385800A for ; Thu, 20 Jan 2022 02:47:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8EE13385800A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-lf1-x132.google.com with SMTP id y15so7857581lfa.9 for ; Wed, 19 Jan 2022 18:47:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KTG33XgohptzjavaMOvfsr//iaz1pGFqdw8+J/uNsR0=; b=WNaXaSOGcpqiUh0Pmj46FiyAr9VR6pBEMI77U6gk0qrxx5uAZaxxg8Fv+an3gggDNx +vlmnEKL03W4JiIMBJDxA9owXOI0Ie/3/4vSLp+Jm28xL1w5pSoPRrTrxX1v1IgA4V3L 02LGrpBUkBGS4scIF30TULrDPOSjN6SnYq7huMqFs1FTHgV4pbJ9sgjOjz4xNzkmNKLG mm8fBw2/WQ84B/sCgnWQA1jldaNw1g8WKNNvxiCEVmFD7pcODO2MqlYaU9QnVI0kuh5M zpA0psrUnHb8IpJ89RS3zbCNUiPJ4UP1J0bXnNUHdVzvhFzuBjgR6RjgTrPhsuPO9ADQ gcOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KTG33XgohptzjavaMOvfsr//iaz1pGFqdw8+J/uNsR0=; b=LLcNCa+xBJlILHTjpC8DAc0dmbGJcuSkN4SUzoGqj4RFOLbGQZCxcDU6OFJryOxLsg mKjt3A4CI/HrQzNanlyGXn7a1cMO65UdgDztSmhZFfbdgc9XIxdQBH40e0g+/U141GeE JUh/KJLES2c9WJMkZpgAvOCb2IUsKzI95otTM7mVVrzS3tPZD194hAhAEH1TIuuTBMTs mPQYVZQNLPipsgBaMKyYlpOGCFuuwjDYvHl8tfF5IIvrOT9geA8vGbK6piyHTx4rf9Sk Z80LrpyOFQyEVB/kH01sDxRx6jv1UY8Kax9vr3ZaoSMhq0sMUWgyDk3qhP0AfRwNRHXJ nynQ== X-Gm-Message-State: AOAM530Y/flEA6FPut3EJbQKMECDM20Nmc9yVpnuXku0XSQ/u1mNmIal z+CYt1D8MCvgoEBDFp0CnuogS8hDjNL9lmCqo/lveQ== X-Google-Smtp-Source: ABdhPJzl7aWQp709NcSvvLeFVZgypVYf4WVopq8uFrGAXUtNlqq9lqzKiDCcz38aamuF8ZdcytiVzdaf3rm12DL72g0= X-Received: by 2002:a05:6512:517:: with SMTP id o23mr1173719lfb.382.1642646841239; Wed, 19 Jan 2022 18:47:21 -0800 (PST) MIME-Version: 1.0 References: <20220118043159.27521-2-vincent.chen@sifive.com> In-Reply-To: From: Kito Cheng Date: Thu, 20 Jan 2022 10:47:10 +0800 Message-ID: Subject: Re: [PATCH v2 1/2] RISC-V: remove riscv-specific sigcontext.h To: Palmer Dabbelt Cc: Vincent Chen , libc-alpha@sourceware.org, Darius Rad , Andrew Waterman , DJ Delorie , Greentime Hu Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-10.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2022 02:47:24 -0000 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 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 > > - . */ > > - > > -#ifndef _BITS_SIGCONTEXT_H > > -#define _BITS_SIGCONTEXT_H 1 > > - > > -#if !defined _SIGNAL_H && !defined _SYS_UCONTEXT_H > > -# error "Never use directly; include 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?