[Bug 207325] projects/clang380-import for TARGET_ARCH=powerpc : c++ exceptions cause SEGV (9 line program)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207325

--- Comment #6 from Mark Millard <markmi at dsl-only.net> ---
I've tracked this down to misbehavior of clang 3.8.0 for __builtin_dwarf_cfa ()
for TARGET_ARCH=powerpc in:

#define uw_init_context(CONTEXT)                                           \
  do                                                                       \
    {                                                                      \
      /* Do any necessary initialization to access arbitrary stack frames. \
         On the SPARC, this means flushing the register windows.  */       \
      __builtin_unwind_init ();                                            \
      uw_init_context_1 (CONTEXT, __builtin_dwarf_cfa (),                  \
                         __builtin_return_address (0));                    \
    }                                                                      \
  while (0)
. . .
85      _Unwind_Reason_Code
86      _Unwind_RaiseException(struct _Unwind_Exception *exc)
87      {
88        struct _Unwind_Context this_context, cur_context;
89        _Unwind_Reason_Code code;
90      
91        /* Set up this_context to describe the current stack frame.  */
92        uw_init_context (&this_context);

In the below r4 ends up with the __builtin_dwarf_cfa () value:

Dump of assembler code for function _Unwind_RaiseException:
   0x419a8fd8 <+0>:     mflr    r0
   0x419a8fdc <+4>:     stw     r31,-148(r1)
   0x419a8fe0 <+8>:     stw     r30,-152(r1)
   0x419a8fe4 <+12>:    stw     r0,4(r1)
   0x419a8fe8 <+16>:    stwu    r1,-2992(r1)
   0x419a8fec <+20>:    mr      r31,r1
. . .
   0x419a9094 <+188>:   mr      r4,r31
   0x419a9098 <+192>:   mflr    r30
   0x419a909c <+196>:   lwz     r5,2996(r31)
   0x419a90a0 <+200>:   mr      r3,r28
   0x419a90a4 <+204>:   bl      0x419a929c <uw_init_context_1>

That r4 ends up holding the stack pointer (r1) value for after it has been
decremented. It is not pointing at the boundary with the caller's frame.

The .eh_frame information and unwind code is set up for it pointing at the
boundary with the caller's frame. So the cfa relative addressing is messed up
for what it actually extracts.

Contrast this with gcc/g++ 5.3's TARGET_ARCH=powerpc64 code where r4 is  made
to be at the boundary with the caller's frame:

Dump of assembler code for function _Unwind_RaiseException:
   0x00000000501cb810 <+0>:     mflr    r0
   0x00000000501cb814 <+4>:     stdu    r1,-5648(r1)
. . .
   0x00000000501cb8d0 <+192>:   addi    r4,r1,5648
   0x00000000501cb8d4 <+196>:   stw     r12,5656(r1)
   0x00000000501cb8d8 <+200>:   mr      r28,r3
   0x00000000501cb8dc <+204>:   addi    r31,r1,2544
   0x00000000501cb8e0 <+208>:   mr      r3,r27
   0x00000000501cb8e4 <+212>:   addi    r29,r1,112
   0x00000000501cb8e8 <+216>:   bl      0x501cae60 <uw_init_context_1>


NOTE: This may in someway be associated with the clang 3.8.0 ABI violation in
how it handles the stack pointer for FreeBSD: TARGET_ARCH=powerpc is currently
using a "red zone", decrementing the stack pointer late, and incrementing the
stack pointer early compared to the ABI rules. (This is similar to the official
FreeBSD ABI for TARGET_ARCH=powerpc64.)

-- 
You are receiving this mail because:
You are the assignee for the bug.