Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 Mar 2014 21:05:19 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Justin Hibbits <chmeeedalf@gmail.com>
Cc:        FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject:   Re: set_mcontext()/grab_mcontext()
Message-ID:  <20140323190519.GW21331@kib.kiev.ua>
In-Reply-To: <20140323093204.203a4a48@zhabar.att.net>
References:  <20140319221325.13f4b7c2@zhabar.att.net> <20140323160046.GU21331@kib.kiev.ua> <20140323093204.203a4a48@zhabar.att.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--JkgDhDyNm4zanevS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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@gmail.com> wrote:
>=20
> > 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.
> > >=20
> > > 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.
> > >=20
> > > 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).
> >=20
> > Late reply, I saw that you already committed r263464.
> >=20
> > 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.
> >=20
> > I think it is useful to keep this behaviour consistent between
> > architectures.
>=20
> 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.
>=20
> 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.

--JkgDhDyNm4zanevS
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)

iQIaBAEBAgAGBQJTLzBuAAoJEJDCuSvBvK1BRpIP7jZLL1JGRlKO9RwtP6f527q7
bZTqNSIAa+RAhwtKkJhkWAGm4otykMhk+gtQ38Pn0BH/Z1dKL2T80NDd6i+aCVFy
C1qN8K+kGF7KkSeteD9Rek0+Cw8Vq4Ij/7jmSIvJ1PhoNIhUdlaOLSycduRuF2Ng
9lc3JJm4Qm6xIcYpQ8w8KxhgA/UQr3bIZ1olrKt6zdtsEKi7U/k6MqdSEBwcIyxz
XUirDFgdPpmP7XVjiOtSrsSGbzX2npOWIN47381XMd9buobgkgbSAvdN4pRIB6td
YfeqWaFS4mbC1LPvoH9QU5AGY3ZlT9C72YMVchNCnyOiOMGCyTRU2FEeVXUmv0RI
+HOUDcNiKmb2NxK2O+mCRB9GGDMgA4uS9JWVFO2QRstbQEVAGoTSIkULtfMFjIAP
3GS+ezdTYPaskYU8yJUg3WyyoaUCTTg+Y1HvmeG9wZGWNV6l3NA3rPyKjuqh3ydC
ea6uL0KzmCFsUvaZQZ0GGvKKjkptkNgMc0z67IHw5mBXj+kOjWshrkNJWvloPtKe
DZ5YDYDoGz/yZEgE4R9It+W1XXFwPtvvXu9+lju/ZnK6TG8OUb/AQznyGkW068lU
bP7lF43ifcSL3mWwmuu0BPxIRSUvZDN+o0R0eNsaSzK2fkHpTMI0rqrVtciSG5oj
PKwrBeAUntyGpzST+w==
=kGN5
-----END PGP SIGNATURE-----

--JkgDhDyNm4zanevS--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140323190519.GW21331>