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=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL 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 ea9f5d1e for ; Tue, 4 Feb 2020 10:04:15 +0000 (UTC) Received: (qmail 9811 invoked by uid 550); 4 Feb 2020 10:04:12 -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 9790 invoked from network); 4 Feb 2020 10:04:12 -0000 X-ASG-Debug-ID: 1580810640-0554131e1e850a20001-j9k7wl X-Barracuda-Envelope-From: mark@dibsco.co.uk X-Barracuda-Effective-Source-IP: cloud209.unlimitedwebhosting.co.uk[149.255.58.38] X-Barracuda-Apparent-Source-IP: 149.255.58.38 Authentication-Results: cloud209.unlimitedwebhosting.co.uk; spf=pass (sender IP is 104.132.132.97) smtp.mailfrom=mark@dibsco.co.uk smtp.helo=laptop.localnet Received-SPF: pass (cloud209.unlimitedwebhosting.co.uk: connection is authenticated) From: Mark Corbin To: musl@lists.openwall.com Cc: Rich Felker Date: Tue, 04 Feb 2020 10:03:59 +0000 X-ASG-Orig-Subj: Re: [musl] REG_SP Definition for RISC-V Message-ID: <2463923.aTGIt9PGv2@laptop> In-Reply-To: <20200203152427.GQ1663@brightrain.aerifal.cx> References: <1815351.tyXQvQ9DpD@laptop> <5347084.5DbCtkH2XI@laptop> <20200203152427.GQ1663@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-PPP-Message-ID: <20200204100359.1547666.47969@cloud209.unlimitedwebhosting.co.uk> X-PPP-Vhost: dibsco.co.uk X-Barracuda-Connect: cloud209.unlimitedwebhosting.co.uk[149.255.58.38] X-Barracuda-Start-Time: 1580810640 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://149.255.60.66:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at thundermail.uk X-Barracuda-Scan-Msg-Size: 3261 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1.9 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.79770 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Subject: Re: [musl] REG_SP Definition for RISC-V On Monday, 3 February 2020 15:24:27 GMT Rich Felker wrote: > On Mon, Feb 03, 2020 at 03:17:15PM +0000, Mark Corbin wrote: > > On Monday, 3 February 2020 13:32:25 GMT Rich Felker wrote: > > > 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 > > > > I spent some time looking for a good method of handling this, but couldn't > > really find any consistency between architectures. I think that most of > > them access the appropriate register array using a numeric value rather > > than a register name in this scenario. > > > > > 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. > > > > I guess that it would probably be best to change the libsigsegv code to > > use a value of '2' instead of the REG_SP definition. I'll look at > > submitting a patch to the project. > > I think using a symbolic name is both more informative and more > portable (since the layout of the saved registers is an OS choice, > nothing universal to the architecture). The question is just where the > macro should be obtained from. As long as glibc (and any other > platforms that might be relevant?) has a sys/reg.h, it wouldn't hurt > to just add the include and continue using the macro, regardless of > whether musl moves it later. > Glibc and uClibc don't have a sys/reg.h - is there a way that it could be included conditionally for musl only? Thanks Mark