powerpc64/GENERIC64: s_trap vs. realtrap, why does realtrap possibly execute restore_kernsrs twice in a row overall?

[Mark Millard]

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