[llvm-bugs] [Bug 26761] New: clang 3.8.0 can mess up __builtin_dwarf_cfa () use, at least for TARGET_ARCH=powerpc

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26761

            Bug ID: 26761
           Summary: clang 3.8.0 can mess up __builtin_dwarf_cfa () use, at
                    least for TARGET_ARCH=powerpc
           Product: clang
           Version: 3.8
          Hardware: Other
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: markmi at dsl-only.net
                CC: dgregor at apple.com, llvm-bugs at lists.llvm.org
    Classification: Unclassified

When run in a TARGET_ARCH=powerpc buildworld based environment that was built
via clang 3.8.0 from FreeBSD's projects/clang380-import source the following 8
line program gets a SEGV. But before it does it ignores the catch clause and
calls std::terminate.

#include <exception>

int main(void)
{
    try { throw std::exception(); }
    catch (std::exception& e) {} // same result without &
    return 0;
}

(The above is a simplification of the original discovery context. The actual
problem code is not in the above source but in supporting FreeBSD library code
when compiled via clang 3.8.0.)

I've tracked down the problem to misbehavior of clang 3.8.0 code generation for
__builtin_dwarf_cfa () as used 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 supplied to
uw_init_context_1:

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 value for after it has been
decremented. r4 is not pointing at the boundary with the caller's frame.

The .eh_frame information and unwind code is set up for 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 some other compiler's TARGET_ARCH=powerpc64 code (for
FreeBSD's projects/clang380-import's source code again) 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>

(clang 3.8.0 is unable to complete a buildworld for FreeBSD last I checked.
Thus my use of another compiler.)

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160227/ea2bb566/attachment.html>