Date: Thu, 14 Mar 2019 18:23:30 -0700 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: llvm submittal 41050 created for powerpc64 C++ exception code generation: ld r2,40(r1) missing or skipped before bl __cxa_begin_catch code Message-ID: <795BBC02-6CE9-401E-8D9F-84FB9FB31364@yahoo.com> In-Reply-To: <2429D922-3214-4D40-9616-56BC0CB93A15@yahoo.com> References: <0AD5D131-C5E3-424E-A276-D960ABDBDFCD@yahoo.com> <2429D922-3214-4D40-9616-56BC0CB93A15@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ELFv2 vs. ELFv1 ABI differences may lead to the fix only applying to one of them: ELFv2's ABI.] On 2019-Mar-13, at 19:14, Mark Millard <marklmi at yahoo.com> wrote: > On 2019-Mar-12, at 22:08, Mark Millard <marklmi at yahoo.com> wrote: >=20 >> I have submitted: >>=20 >> https://bugs.llvm.org//show_bug.cgi?id=3D41050 >>=20 >> for the clang 8 code generation problem of >> no code for setting r2 appropriately before >> the: >>=20 >> bl . . . <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> >>=20 >> in unoptimized code ( no -O ). For the -O2 code: >>=20 >> ld r2,40(r1) >>=20 >> is present but is being skipped by the libunwind return >> to the code: it returns to the just-following bl >> instruction (like above) instead. >>=20 >> In both cases: >>=20 >> (gdb) x/32i 0x100007c0 >> 0x100007c0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3>: = std r2,40(r1) >> 0x100007c4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+4>: = ld r12,-32608(r2) >> 0x100007c8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+8>: = mtctr r12 >> 0x100007cc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+12>: = ld r11,-32592(r2) >> 0x100007d0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+16>: = ld r2,-32600(r2) >> 0x100007d4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+20>: = bctr >> 0x100007d8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+24>: = .long 0x0 >> 0x100007dc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+28>: = .long 0x0 >> . . . >>=20 >> with an inappropriate r2 value leads to jumping to >> inappropriate places. >>=20 >> The example source code was: >>=20 >> #include <exception> >>=20 >> int main(void) >> { >> try { throw std::exception(); } >> catch (std::exception& e) {} >> return 0; >> } >>=20 >>=20 >>=20 >> Note: >>=20 >> This is from investigations of head -r345044 using >> WITH_LLVM_LIBUNWIND=3D on powerpc64. >>=20 >=20 > The discussion on https://bugs.llvm.org//show_bug.cgi?id=3D41050 > indicates that the ld r2,??? to restore the value appropriate to > the a.out code in my example should be happening via the library > holding libunwind's code instead of the ld executing in the > a.out code. >=20 > So: thus far it is viewed as a libunwind issue instead of a clang > one. Both ELFv2 and ELFv1 are currently broken because of r2 (TOC) mishanding. Looks like that when libunwind is fixed, it might not support the ELFv1 ABI (just the ELFv2 ABI): handling r2 (TOC) is different because of the differences in the stack frame header . . . ELFv1 has r2 save area at 40(r1) [because of the compiler and = link-editor doublewords] ELFV2 has r2 save area at 24(r1) [no compiler or link-editor = doublewords] A simple update to libunwind/src/UnwindRegistersRestore.S for = powerpc64's _ZN9libunwind15Registers_ppc646jumptoE is (an ELFv2 ABI example): - PPC64_LR(2) + // skip r2 for now and: PPC64_LR(4) PPC64_LR(1) PPC64_LR(3) + ld %r2, 24(%r1) bctr (That is from comment #16.) I've no clue if more would be done to handle the ELFv1 ABI as well. As I understand FreeBSD plans to support the ELFv2 ABI at some point. I'm not sure of the intent after that for the ELFv1 ABI. =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?795BBC02-6CE9-401E-8D9F-84FB9FB31364>