set_mcontext()/grab_mcontext()

[Konstantin Belousov]

On Sun, Mar 23, 2014 at 09:32:04AM -0700, Justin Hibbits wrote:
> On Sun, 23 Mar 2014 18:00:46 +0200
> Konstantin Belousov <kostikbel at gmail.com> wrote:
> 
> > On Wed, Mar 19, 2014 at 10:13:25PM -0700, Justin Hibbits wrote:
> > > Running into problems with X exiting during a sigreturn(2) on my G4
> > > PowerBooks, it seems sometimes bit 10 is set in the mc_srr1 field,
> > > which, from the documentation, can only be set by hardware on an
> > > external interrupt.
> > > 
> > > Looking at the references closer, bits 1-4, 10-15 (ppc32), also
> > > numbered as bits 33-36, 42-47 (ppc64) are for exception-specific
> > > information only.  I'm wondering if it makes sense to mask these off
> > > when setting and getting the context, as those bits are useless
> > > upon an rfi.
> > > 
> > > I know this is probably simply a band-aid for possible corruption
> > > in X, but to me it makes sense, as the context data is useful only
> > > when entering the interrupt context, not when context is restored
> > > (bits are localized, not restored to MSR).
> > 
> > Late reply, I saw that you already committed r263464.
> > 
> > Traditionally, the sigreturn(2)/setcontext(2) are strict, in
> > particular, on FreeBSD. E.g., on i386/amd64 any reserved bit in
> > %{e.r}flags, which is closest analog of PPC msr, or even a reserved
> > flag in the software-defined mc_flags field, cause EINVAL. Due to the
> > construction of the signal trampoline code, return from sigreturn(2)
> > without applying passed context causes trap.
> > 
> > I think it is useful to keep this behaviour consistent between
> > architectures.
> 
> I understand, and agree.  The difference, however, is that on AIM
> architecture (Book-E does it differently) the bits I listed above are
> only in srr1.  They're not propogated back to the MSR.  They're not
> even marked as reserved in the MSR, because some of them overlap (bit
> 12(ppc32) is the POW bit in MSR, but anything in srr1, for example).
> After discussing with Nathan, we decided that masking these bits is
> appropriate.
> 
> In your opinion, would a more appropriate route be to mask these bits
> out in grab_mcontext() instead, and keep the formerly strict checking
> in set_mcontext()?  As I mentioned before, those bits are checked only
> on entry to the trap, to decide how to handle the trap.  Once that's
> done, they're completely useless in srr1, and srr1 (ergo, tf->srr1) gets
> overwritten on every exception.

Do the bits provide useful information to the signal handler ?
In other words, would masking the bits in getcontext()/sendsig()
make the signal handler operate with less information ?  If no,
then masking them on entry instead of exit is indeed appropriate.
Otherwise, I agree with your arguments.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ppc/attachments/20140323/667d541d/attachment.sig>