Date: Tue, 2 Apr 2019 14:52:01 -0700 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: powerpc64 r13 setjmp/longjmp use; 32-bit setjmp/longjmp powerpc r2 use; they look a little odd to me (but operational) Message-ID: <246BE62D-16B7-4D87-BF3C-A5172DF91425@yahoo.com>
next in thread | raw e-mail | index | archive | help
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.s= o.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.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?246BE62D-16B7-4D87-BF3C-A5172DF91425>