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=DKIM_SIGNED,DKIM_VALID, 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 66fb34d1 for ; Tue, 18 Feb 2020 19:17:47 +0000 (UTC) Received: (qmail 29856 invoked by uid 550); 18 Feb 2020 19:17:44 -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 29835 invoked from network); 18 Feb 2020 19:17:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20150623.gappssmtp.com; s=20150623; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=6I1odi/2wRn6280nJZtExJsmwUGPRH6Kl7FZJCLWX2w=; b=hppArfw9Z+Wx30s5TLAkdABN9ivU2wV7yIZnb1HiOoBB/kZgqQ/t4a1EB2y7y6Vmid JYhcc9+Re+Ve+/Y5cY0OmHpawRHicSM+ZNJ70psD0rGNM653yk3JnUrVicE+o9EQE3AI mTmoQKR+UTzQlfVFwehauKPYPqn1GglcP54PE/XYPgfy+OAOh1rphcPay91VrwFilj3+ lr4Mh7Dy5ErsexOvDG5sg3teR7dvYMiW5idXrAKK3Inrl3hOlbYec6SJwXHTzWNfM/2r znbyYW+za/i8N7mO3TvMWVRPUgKrnvZPPoE8TLWdNj0xielLi/82mQSuz8BManyPVy7L xIqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=6I1odi/2wRn6280nJZtExJsmwUGPRH6Kl7FZJCLWX2w=; b=mm1NdRDo+HuYg+6BzaEGsUwkzr7f8IrEI4/0XOH71E6asBDy51a0k/dsGQQUMmpFUJ G+KK2FAuC9m5RWOhq5HH7JFmRu6mcn0xGZ0JiuVCWopbLXoxd4uOlTK1Xft5lA2Sdv6U 13yTpVHLe/AzaGi97MYAn8Gv4BV6nIL9pt2c9dS3FcOOsGSOQoo3u/iEHHaQCpunERZM 96YJFjQPNDaHlqCy6GgEVNhJUUBktwbbJ2y2iTCKHBxtPyo8Cc9y9m/CPrY6MYh97sq2 SrVbetJd2J6XsKVJndR2itpB/T3LcWwYHrFCPu/bXGeITUg/mJWFQQhmXv5gSmdxJmR1 s+NA== X-Gm-Message-State: APjAAAWbcuPIvVNvhmMLYmZGz/83CYcWFS9uiQO1EhiplvL2p/q62wKk 7jjjiKrtuzjIrcENSaucPfYbxQ== X-Google-Smtp-Source: APXvYqwgKIYXVSsUGhQS1Sq3dru+kkgeg5sAOBkelflinl3A4lAZ98Ve4rxJjNZtNERdX5f5ZT9RFA== X-Received: by 2002:a17:90b:3109:: with SMTP id gc9mr4469494pjb.30.1582053451070; Tue, 18 Feb 2020 11:17:31 -0800 (PST) Date: Tue, 18 Feb 2020 11:17:30 -0800 (PST) X-Google-Original-Date: Tue, 18 Feb 2020 11:17:29 PST (-0800) In-Reply-To: <20200204142631.GU1663@brightrain.aerifal.cx> CC: mark@dibsco.co.uk, musl@lists.openwall.com From: Palmer Dabbelt To: dalias@libc.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [musl] REG_SP Definition for RISC-V On Tue, 04 Feb 2020 06:26:31 PST (-0800), dalias@libc.org wrote: > On Tue, Feb 04, 2020 at 10:03:59AM +0000, Mark Corbin wrote: >> 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? > > If you want a configure test to detect it the yes; otherwise no. But > this suggests the way we did it is wrong. We should not be making this > kind of mess. I should probably just move the definitions... The glibc definitions are in sys/ucontext.h as that's also where the relevant structures are defined. They're all within a _GNU_SOURCE to avoid polluting the namespace too much. Maybe the best bet is to have a riscv64-specific sys/ucontext.h? I don't see any other ports with their own sys/ucontext.h, though.