From owner-freebsd-ppc@FreeBSD.ORG Fri Oct 10 16:28:23 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D885A403 for ; Fri, 10 Oct 2014 16:28:23 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7ED25FCB for ; Fri, 10 Oct 2014 16:28:22 +0000 (UTC) Received: (qmail 8789 invoked from network); 10 Oct 2014 16:28:20 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 10 Oct 2014 16:28:20 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Fri, 10 Oct 2014 12:28:20 -0400 (EDT) Received: (qmail 24760 invoked from network); 10 Oct 2014 16:28:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Oct 2014 16:28:20 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id CB2261C4056; Fri, 10 Oct 2014 09:28:16 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: powerpc64/GENERIC64: s_trap vs. realtrap, why does realtrap possibly execute restore_kernsrs twice in a row overall? From: Mark Millard In-Reply-To: <5437F9EB.3050302@freebsd.org> Date: Fri, 10 Oct 2014 09:28:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0780902E-CF13-402A-A17B-4A2484CE008F@dsl-only.net> References: <511C0B85-173F-4863-ACA5-0274C381E005@dsl-only.net> <5437F9EB.3050302@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1878.6) Cc: Justin Hibbits , FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 16:28:24 -0000 On Oct 10, 2014, at 8:23 AM, Nathan Whitehorn = wrote: > How does this end up being called twice? k_trap does not return (note = no "l" in the branch instruction). They are separated, by the way, due = to some slightly different logic for handling faults that need to end up = in the kernel debugger. If I read the above right you have answered for when "bf 17,k_trap" is = taken in realtrap and so realtrap's "ba s_strap" is not even executed. = But I specified that my worry was for when "presuming that the original = 'bd 17,k_trap' in realtrap is not taken". May be showing the flow in sequential order (for both reading and = execution) starting at realtrap when "bf 17, k_trap" is not taken in the = following manor will help with interpretation of my point: Read = sequentially down the listing below where the conditional branches do = not jump to k_trap. It only flows there (no jump) after the code shown = for s_trap below for the case/context I was asking about unless I've = missed something. I've also added to the comments to help identify my = intended case. realtrap: /* Test whether we already had PR set */ mfsrr1 %r1 mtcr %r1 mfsprg1 %r1 /* restore SP (might have been overwritten) */ bf 17,k_trap /* branch if PSL_PR is false PRESUME PSL_PR IS = TRUE INSTEAD */ GET_CPUINFO(%r1) ld %r1,PC_CURPCB(%r1) mr %r27,%r28 /* Save LR, r29 */ mtsprg2 %r29 bl restore_kernsrs /* enable kernel mapping <=3D=3D=3D = FIRST CALL */ mfsprg2 %r29 mr %r28,%r27 ba s_trap s_trap: bf 17,k_trap /* branch if PSL_PR is false STILL NO BRANCH? = */ GET_CPUINFO(%r1) ld %r1,PC_CURPCB(%r1) mr %r27,%r28 /* Save LR, r29 */ mtsprg2 %r29 bl restore_kernsrs /* enable kernel mapping <=3D=3D=3D = SECOND CALL */ mfsprg2 %r29 mr %r28,%r27 This would then finally flow into k_trap but my point has already = happened by this point. I see two calls to restore_kernsrs when I read = the above execution sequence when PSL_PR is TRUE for the first "bf = 17,k_trap" (so no jump). So far I do not see code executed for this = sequence that would make the second "bf 17,k_trap" jump when the first = one above did not. Did I miss something in restore_kernsrs that makes = the 2nd "bf 17,k_trap" jump when the first one does not? (I saw the logic for the kernel debugger vs. normal. I did not challenge = why the two alternatives exist. It just appears to me that there is some = redundant work done by one path through the code.) =3D=3D=3D Mark Millard markmi at dsl-only.net