From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 2286B3857C7E for ; Thu, 20 Jan 2022 02:36:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2286B3857C7E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pf1-x42c.google.com with SMTP id i65so4041520pfc.9 for ; Wed, 19 Jan 2022 18:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=yeBLzTeTz+J+Lv0XSSMEW89B7ABhJ72htz+RLkp0oMQ=; b=iP3mJ02Iy1CBxuZ76vygyNQUdMb7RSnKwM5s8AcQViRzs4HbqJNkUV4rd5YCj8xL39 3QtZxzSofOnwSdYSXePjgAzFHFp/k8ra8yTi6yHW1wLgIsw/iuf1O4og/LRTxTVYC/gt CRvVjzdKuLwTSpdAEe96ySbm20iE8GshztBrSyp1FDlVdZ+OwSe044lR82XHz1QsMDdW Wau1VF7l0Dnw4B5PPstj1EVL/TZWNLm7XVosPBbw5/D0Yw/QqdMPLT7fKcoRuXMXNYf2 mzaGkg3GKCB2Z7wCpAZklHmi1nu3ykvJ7GuTdzN37U8H+OE/SrkabtgZK3MsBEBVNoYl o/sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=yeBLzTeTz+J+Lv0XSSMEW89B7ABhJ72htz+RLkp0oMQ=; b=Vg7YF2XwPYoE2zqH/KM37B8LyHa5OzFkpqE+krunmgVJbw441Y/Sg4OpMJgBUNMmEg wJ4FHh8mMxjww0H7s8qr83JD4z1/cewTgvcR6v30c57XB7fKAcw+ITHEkMiA92SsNkip n99EXGpXyA/ukt9JLtuxh2440NibCqYjhN0ly+2UpoPHlu0xzjKL8ixH78FG08f6UHiQ cvDj2Fh01SWHpUgWAuIBTeHjTYjs2Q2ERIwK8rcT6mmTSkyW2eeZ/bbBRFIuzxl2dmAL fJp4Ty3YKwu1MD6RdGFngOAl4K5M3eeBu6TXCwR4srIoTaeCo5rM4gV4r7jB4/sXG924 eRkw== X-Gm-Message-State: AOAM532BrIW3TVAfzMJ0DuCAsBa7zM6SxMYaTmhFWqxtuZxk0OKgOZYY YtVerIcbIwfK7YWQFdO5DuOfkUIzdfBqLQ== X-Google-Smtp-Source: ABdhPJwajIhQZjup3SduOof2ucQRayfH3oeYaB5S+A4naSDMgUbIpqgOHjeHhTST4eU2yzI3CTWAuA== X-Received: by 2002:a63:8f09:: with SMTP id n9mr29668650pgd.308.1642646189826; Wed, 19 Jan 2022 18:36:29 -0800 (PST) Received: from localhost ([12.3.194.138]) by smtp.gmail.com with ESMTPSA id x12sm787987pge.58.2022.01.19.18.36.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jan 2022 18:36:29 -0800 (PST) Date: Wed, 19 Jan 2022 18:36:29 -0800 (PST) X-Google-Original-Date: Wed, 19 Jan 2022 18:36:01 PST (-0800) Subject: Re: [PATCH v2 1/2] RISC-V: remove riscv-specific sigcontext.h In-Reply-To: <20220118043159.27521-2-vincent.chen@sifive.com> CC: libc-alpha@sourceware.org, Darius Rad , Andrew Waterman , dj@redhat.com, kito.cheng@sifive.com, greentime.hu@sifive.com, vincent.chen@sifive.com From: Palmer Dabbelt To: vincent.chen@sifive.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, 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:36:36 -0000 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?