llvm submittal 41050 created for powerpc64 C++ exception code generation: ld r2,40(r1) missing or skipped before bl __cxa_begin_catch code

[Mark Millard]

[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)