|
Message-ID: <5347084.5DbCtkH2XI@laptop> Date: Mon, 03 Feb 2020 15:17:15 +0000 From: Mark Corbin <mark@...sco.co.uk> To: musl@...ts.openwall.com Cc: Rich Felker <dalias@...c.org> Subject: Re: REG_SP Definition for RISC-V 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 <sys/reg.h>. I'm not sure if there's any precedent for > that or if glibc only has them in <signal.h> 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 <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. 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. Thanks Mark Corbin
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.