[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: > >> I have submitted: >> >> https://bugs.llvm.org//show_bug.cgi?id=41050 >> >> for the clang 8 code generation problem of >> no code for setting r2 appropriately before >> the: >> >> bl . . . <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> >> >> in unoptimized code ( no -O ). For the -O2 code: >> >> ld r2,40(r1) >> >> is present but is being skipped by the libunwind return >> to the code: it returns to the just-following bl >> instruction (like above) instead. >> >> In both cases: >> >> (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 >> . . . >> >> with an inappropriate r2 value leads to jumping to >> inappropriate places. >> >> The example source code was: >> >> #include <exception> >> >> int main(void) >> { >> try { throw std::exception(); } >> catch (std::exception& e) {} >> return 0; >> } >> >> >> >> Note: >> >> This is from investigations of head -r345044 using >> WITH_LLVM_LIBUNWIND= on powerpc64. >> > > The discussion on https://bugs.llvm.org//show_bug.cgi?id=41050 > 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. > > 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. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
