From owner-freebsd-ppc@FreeBSD.ORG Fri Oct 10 15:33:49 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 DF16DA3 for ; Fri, 10 Oct 2014 15:33:48 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BA27E9FD for ; Fri, 10 Oct 2014 15:33:48 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s9AFNNHI025513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Oct 2014 08:23:24 -0700 Message-ID: <5437F9EB.3050302@freebsd.org> Date: Fri, 10 Oct 2014 08:23:23 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Mark Millard , FreeBSD PowerPC ML Subject: Re: powerpc64/GENERIC64: s_trap vs. realtrap, why does realtrap possibly execute restore_kernsrs twice in a row overall? References: <511C0B85-173F-4863-ACA5-0274C381E005@dsl-only.net> In-Reply-To: <511C0B85-173F-4863-ACA5-0274C381E005@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZhl1VmBHvuleyMLE+Nk01HpDzvcmFlJqzTXBZBb4XS8Pxu2j/yTt4Bh7CP7Qp5j7U/z89Bfk2obqCL2QdYj4TRDGpbnO8hDHw= X-Sonic-ID: C;IF+zX5FQ5BG1xYR6lZB5Vg== M;dvgxYJFQ5BG1xYR6lZB5Vg== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Cc: Justin Hibbits 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 15:33:49 -0000 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. -Nathan On 10/10/14 08:04, Mark Millard wrote: > Based on 10.1-RC1 sources but probably long true.. > > s_trap in /usr/src/sys/powerpc/aim/trap_subr64.S starts with the following sequence of 8 lines of source immediately after the s_trap label (ignoring the unused u_trap label line, not shown below): > > s_trap: > bf 17,k_trap /* branch if PSL_PR is false */ > GET_CPUINFO(%r1) > ld %r1,PC_CURPCB(%r1) > mr %r27,%r28 /* Save LR, r29 */ > mtsprg2 %r29 > bl restore_kernsrs /* enable kernel mapping */ > mfsprg2 %r29 > mr %r28,%r27 > > > realtrap also has that exact instruction sequence starting a few instructions down in its code --but immeadiately followed by a branch to s_strap that ends up reexecuting that same instruction sequence (but in/at s_trap), presuming that the original "bd 17,k_trap" in realtrap is not taken: > > 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 */ > GET_CPUINFO(%r1) > ld %r1,PC_CURPCB(%r1) > mr %r27,%r28 /* Save LR, r29 */ > mtsprg2 %r29 > bl restore_kernsrs /* enable kernel mapping */ > mfsprg2 %r29 > mr %r28,%r27 > ba s_trap > > Why would this code for possibly calling restore_kernsrs possibly be executed twice back-to-back for realtrap's execution overall? Is this deliberate for some reason? Could the realtrap code validly avoid the doubled activity when it does not immediately jump to k_trap? > > Note that if it was possible for s_trap to take the "bf 17,k_trap" branch after realtrap did its "ba s_trap" then %r1 for that s_trap use would not have the stack pointer in it for k_trap's potential use (e.g., in its use of FRAME_SETUP). restore_kernsrs does not touch %r1 and k_trap takes %r1 as-is for use as a stack pointer in FRAME_SETUP. Luckily it appears that s_trap would not take that branch in this context. > > But if that last is true that means that s_trap's code definitely always does call restore_kernsrs a second time when used from realtrap. Wasteful? > > > [And for realtrap it would seem that the "mfsrr1 %r1" definitely "might have" overwritten %r1 (a.k.a. the Stack Pointer): The "might have" comment seems a little odd. It is more like the SP would be needed in the branch to k_trap case and so had to be put back in %r1 to cover that.] > > > > > > > === > Mark Millard > markmi at dsl-only.net > >