[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20171105163308.GI1627@brightrain.aerifal.cx>
Date: Sun, 5 Nov 2017 11:33:08 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: SIGSEGV_FAULT_STACKPOINTER on powerpc
On Sun, Nov 05, 2017 at 01:30:53PM +0100, Szabolcs Nagy wrote:
> * Tobias Koch <tobias.koch@...terra.com> [2017-11-05 11:28:08 +0000]:
> >
> > libsigsegv defines SIGSEGV_FAULT_STACKPOINTER in fault-linux-powerpc.h as
> >
> > # define SIGSEGV_FAULT_STACKPOINTER ((ucontext_t *) ucp)->uc_mcontext.regs->gpr[1]
> >
> > which doesn't match up with what's defined in musl's arch/powerpc/bits/signal.h. I took a guess and changed it to
> >
> > # define SIGSEGV_FAULT_STACKPOINTER ((ucontext_t *) ucp)->uc_mcontext.gregs[1]
> >
> > to make it compile, but I don't know if that is correct. I'd appreciate any help.
> >
>
> in glibc uc_mcontext member of ucontext_t is an union of
> pt_regs* (linux ptrace.h defines it) and mcontext_t* (same
> as in musl). but the standard requires mcontext_t there,
> not an union of pointers, so the powerpc linux abi is broken.
>
> to access gpregs in glibc you can use either of
>
> (pt_regs*) ucp->uc_mcontext.regs
> (mcontext_t*) ucp->uc_mcontext.uc_regs
>
> in musl it's
>
> (mcontext_t*) ucp->uc_regs
This is legacy and should not be used. The right way is just accessing
ucp->uc_mcontext, which has structure type, not pointer.
> the pointers may point to the tail of the ucontext_t struct
> where musl has its ucp->uc_mcontext field with the right type,
> but i don't know if that's guaranteed.
It's intended by musl that it's a guarantee (if someone _really_ wants
to break this on the kernel side, we might have to finally do libc
interception-and-rewrite of signal handling...) and as far as I know
it's guaranteed on all modern kernels. The compat mess with the
pointer stuff was from ancient times, 2.4 or maybe even 2.2, IIRC.
Note that we access uc_mcontext internally in musl (cancellation), so
if it broke, there would be internal breakage in musl, not just
breakage for applications using it.
> so the standard conform way (using ucp->uc_mcontext) to
> access the registers is not reliable. you can try to use the
> non-standard uc_regs pointer:
>
> #ifdef __GLIBC__
> #define uc_regs uc_mcontext.uc_regs
> #endif
> #define SIGSEGV_FAULT_STACKPOINTER ((ucontext_t *) ucp)->uc_regs->gregs[1]
This could be done, but I would encourage access via the standard
interface (uc_mcontext) to help establish that it is the standard and
a kernel ABI property that must be preserved.
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.
