From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 23 19:05:24 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88C62936 for ; Sun, 23 Mar 2014 19:05:24 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 06CF6A64 for ; Sun, 23 Mar 2014 19:05:23 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s2NJ5JMR060834; Sun, 23 Mar 2014 21:05:19 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2NJ5JMR060834 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2NJ5JdM060833; Sun, 23 Mar 2014 21:05:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 23 Mar 2014 21:05:19 +0200 From: Konstantin Belousov To: Justin Hibbits Subject: Re: set_mcontext()/grab_mcontext() Message-ID: <20140323190519.GW21331@kib.kiev.ua> References: <20140319221325.13f4b7c2@zhabar.att.net> <20140323160046.GU21331@kib.kiev.ua> <20140323093204.203a4a48@zhabar.att.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JkgDhDyNm4zanevS" Content-Disposition: inline In-Reply-To: <20140323093204.203a4a48@zhabar.att.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 19:05:24 -0000 --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 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--