Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 3 Feb 2020 08:32:25 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Cc: Mark Corbin <mark@...sco.co.uk>
Subject: Re: 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 <sys/reg.h>. I'm not sure if there's any precedent for
that or if glibc only has them in <signal.h>

So my leaning would be to leave it as it is and ask applications to
include <sys/reg.h> 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 <signal.h> like
many other archs do.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.