powerpc64 r13 setjmp/longjmp use; 32-bit setjmp/longjmp powerpc r2 use; they look a little odd to me (but operational)

[Mark Millard]

In looking around to find what to expect for
32-bit powerpc r2 handling I ran into things
that look a little odd to me for both powerpc64
(r13) and 32-bit powerpc (r2): setjmp/longjmp
handling of those registers. head -r345758 based
for the below examples, system-clang did the
buildworld's involved.


powerpc64 r13 handling for a system-clang-based buildworld:

r13 is saved to 72(r6) but never restored from 72(r3). The
location for 72(r6) seems to be write only. (Recorded for
debugging use? It is not obvious that it should be saved
at all, given the _set_tp r13 use related to thread-local
storage.)

# objdump -d --prefix-addresses /usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils-poud/lib/libc.so.7 | egrep -C3 '(_set_tp|.*jmp.*).*(\<r13\>|[^0-9]72\(r)' | more
00000000000a4d68 <.__getcontextx+0x94> blr
        ...
00000000000a4d78 <._set_tp> addi    r3,r3,28688
00000000000a4d7c <._set_tp+0x4> mr      r13,r3
00000000000a4d80 <._set_tp+0x8> blr
        ...
00000000000a4d90 <.__syncicache> mflr    r0
--
00000000000a50cc <.sigsetjmp+0x4c> stfd    f16,240(r6)
00000000000a50d0 <.sigsetjmp+0x50> std     r12,64(r6)
00000000000a50d4 <.sigsetjmp+0x54> stfd    f17,248(r6)
00000000000a50d8 <.sigsetjmp+0x58> std     r13,72(r6)
00000000000a50dc <.sigsetjmp+0x5c> stfd    f18,256(r6)
00000000000a50e0 <.sigsetjmp+0x60> std     r14,80(r6)
00000000000a50e4 <.sigsetjmp+0x64> stfd    f19,264(r6)
--
00000000000a52b0 <.setjmp+0x40> stfd    f16,240(r6)
00000000000a52b4 <.setjmp+0x44> std     r12,64(r6)
00000000000a52b8 <.setjmp+0x48> stfd    f17,248(r6)
00000000000a52bc <.setjmp+0x4c> std     r13,72(r6)
00000000000a52c0 <.setjmp+0x50> stfd    f18,256(r6)
00000000000a52c4 <.setjmp+0x54> std     r14,80(r6)
00000000000a52c8 <.setjmp+0x58> stfd    f19,264(r6)
--
00000000000a5474 <._setjmp+0x24> stfd    f16,240(r3)
00000000000a5478 <._setjmp+0x28> std     r12,64(r3)
00000000000a547c <._setjmp+0x2c> stfd    f17,248(r3)
00000000000a5480 <._setjmp+0x30> std     r13,72(r3)
00000000000a5484 <._setjmp+0x34> stfd    f18,256(r3)
00000000000a5488 <._setjmp+0x38> std     r14,80(r3)
00000000000a548c <._setjmp+0x3c> stfd    f19,264(r3)

(It appears that C++ exception handling should not be saving
or adjusting r13 for powerpc64.)


32-bit powerpc handling for a system-clang-based buildworld:

r2 is saved to 20(r6) (first going through r9) but restored
to r9 via 20(r3), never going back to r2. (Recorded for
debugging use? It is not obvious that it should be saved at
all [or restored to r9], given the _set_tp r2 use related to
thread-local storage.)

# objdump -d --prefix-addresses /usr/obj/DESTDIRs/gcc421-powerpc-installworld/lib/libc.so.7 | egrep -C3 '(_set_tp|.*jmp.*).*(\<r2\>|[^0-9]20\(r)' | more
0005bee8 <sigsetjmp+0x28> mflr    r11
0005beec <sigsetjmp+0x2c> mfcr    r12
0005bef0 <sigsetjmp+0x30> mr      r10,r1
0005bef4 <sigsetjmp+0x34> mr      r9,r2
0005bef8 <sigsetjmp+0x38> stmw    r9,20(r6)
0005befc <sigsetjmp+0x3c> stfd    f14,112(r6)
0005bf00 <sigsetjmp+0x40> stfd    f15,120(r6)
0005bf04 <sigsetjmp+0x44> stfd    f16,128(r6)
--
0005bf44 <sigsetjmp+0x84> li      r3,0
0005bf48 <sigsetjmp+0x88> blr
0005bf4c <sigsetjmp+0x8c> nop
0005bf50 <siglongjmp> lmw     r9,20(r3)
0005bf54 <siglongjmp+0x4> lfd     f14,112(r3)
0005bf58 <siglongjmp+0x8> lfd     f15,120(r3)
0005bf5c <siglongjmp+0xc> lfd     f16,128(r3)
--
0005bffc <setjmp+0x1c> mflr    r11
0005c000 <setjmp+0x20> mfcr    r12
0005c004 <setjmp+0x24> mr      r10,r1
0005c008 <setjmp+0x28> mr      r9,r2
0005c00c <setjmp+0x2c> stmw    r9,20(r6)
0005c010 <setjmp+0x30> stfd    f14,112(r6)
0005c014 <setjmp+0x34> stfd    f15,120(r6)
0005c018 <setjmp+0x38> stfd    f16,128(r6)
--
0005c054 <setjmp+0x74> stfd    f31,248(r6)
0005c058 <setjmp+0x78> li      r3,0
0005c05c <setjmp+0x7c> blr
0005c060 <__longjmp> lmw     r9,20(r3)
0005c064 <__longjmp+0x4> lfd     f14,112(r3)
0005c068 <__longjmp+0x8> lfd     f15,120(r3)
0005c06c <__longjmp+0xc> lfd     f16,128(r3)
--
0005c0f0 <_setjmp> mflr    r11
0005c0f4 <_setjmp+0x4> mfcr    r12
0005c0f8 <_setjmp+0x8> mr      r10,r1
0005c0fc <_setjmp+0xc> mr      r9,r2
0005c100 <_setjmp+0x10> stmw    r9,20(r3)
0005c104 <_setjmp+0x14> stfd    f14,112(r3)
0005c108 <_setjmp+0x18> stfd    f15,120(r3)
0005c10c <_setjmp+0x1c> stfd    f16,128(r3)
--
0005c154 <_setjmp+0x64> nop
0005c158 <_setjmp+0x68> nop
0005c15c <_setjmp+0x6c> nop
0005c160 <_longjmp> lmw     r9,20(r3)
0005c164 <_longjmp+0x4> lfd     f14,112(r3)
0005c168 <_longjmp+0x8> lfd     f15,120(r3)
0005c16c <_longjmp+0xc> lfd     f16,128(r3)
--
0005c3a0 <getcontextx+0x78> b       0005c364 <getcontextx+0x3c>
0005c3a4 <_set_tp> stwu    r1,-32(r1)
0005c3a8 <_set_tp+0x4> addi    r3,r3,28680
0005c3ac <_set_tp+0x8> mr      r2,r3
0005c3b0 <_set_tp+0xc> addi    r1,r1,32
0005c3b4 <_set_tp+0x10> blr
0005c3b8 <__syncicache> stwu    r1,-64(r1)

(It appears that C++ exception handling should not be saving
or adjusting r2 for 32-bit powerpc.)


(I had remembered that there was something odd with
32-bit powerpc r2 handling but had forgotten the
details. Until rediscovering the above, it had left
me wondering if C++ exception handling should involve
adjusting r2 or not for FreeBSD. I've worded some prior
list submittals presuming save/restore was appropriate
for C++ exception handling. That was wrong.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)