From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SUBJ_OBFU_PUNCT_FEW autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 44043974 for ; Mon, 3 Feb 2020 13:32:39 +0000 (UTC) Received: (qmail 19955 invoked by uid 550); 3 Feb 2020 13:32:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 19937 invoked from network); 3 Feb 2020 13:32:37 -0000 Date: Mon, 3 Feb 2020 08:32:25 -0500 From: Rich Felker To: musl@lists.openwall.com Cc: Mark Corbin Message-ID: <20200203133225.GO1663@brightrain.aerifal.cx> References: <1815351.tyXQvQ9DpD@laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1815351.tyXQvQ9DpD@laptop> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] REG_SP Definition for RISC-V On Mon, Feb 03, 2020 at 11:42:30AM +0000, Mark Corbin wrote: > Hello > > I'm trying to fix a build issue with libsigsegv [1] for RISC-V when compiling > against musl 1.1.24 (under Buildroot). > > The build fails because the array index 'REG_SP' (for indexing into > uc_mcontext.__gregs[]) is not defined in arch/riscv64/bits/signal.h. This > constant is defined by glibc in sysdeps/unix/sysv/linux/riscv/sys/ucontext.h > > I was wondering whether the appropriate fix is just to add '#define REG_SP 2' to > the top of arch/riscv64/bits/signal.h ? (Note that there is a REG_SP definition > in arch/riscv64/bits/reg.h which isn't being included). > > Alternatively I could submit a patch to libsigsegv to modify the index into > the '__gregs' array to be '2' rather than 'REG_SP', however there could be > other glibc compatible RISC-V packages that make use of the 'REG_SP' > definition. > > I'm happy to generate and submit any patches as appropriate. Generally, we like to avoid this kind of REG_* (or even bare names) register macro in signal.h since it's highly namespace-polluting (can break software using them for its own purposes that has no knowledge that some arch has a reg by that name in its signal.h bits) and only expose them under _GNU_SOURCE when we do. Right now musl has them exposed via . I'm not sure if there's any precedent for that or if glibc only has them in So my leaning would be to leave it as it is and ask applications to include if they want these macros. But if it looks like this is contrary to what maintainers of other software want to do, we could consider putting them under _GNU_SOURCE with like many other archs do. Rich