[LLVMbugs] [Bug 16298] New: llvm.eh.unwind.init() is mostly a no-op, which subtly breaks libgcc_eh

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=16298

            Bug ID: 16298
           Summary: llvm.eh.unwind.init() is mostly a no-op, which subtly
                    breaks libgcc_eh
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
          Assignee: unassignedbugs at nondot.org
          Reporter: mseaborn at chromium.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

If libgcc_eh is built with Clang + LLVM, it is subtly broken, because
__builtin_unwind_init() is compiled to the llvm.eh.unwind.init() intrinsic,
which is largely a no-op.

__builtin_unwind_init() is supposed to cause the function's prologue and
epilogue to save and restore all registers, but llvm.eh.unwind.init() doesn't
have this effect.  _Unwind_RaiseException(), _Unwind_Resume() etc. use other
GCC builtins to get the address of the register save area and modify the saved
register values, before calling __builtin_eh_return() to return and modify the
stack pointer at the same time.

This means that when libgcc_eh is compiled with LLVM, _Unwind_RaiseException(),
_Unwind_Resume() etc. won't necessarily restore all registers properly when
unwinding the stack to handle a C++ exception.  If they work, it's by luck.

It would be better if __builtin_unwind_init() were rejected at compile time,
rather than being accepted but not having the intended effect.

See also this PNaCl bug:
https://code.google.com/p/nativeclient/issues/detail?id=3486

-- 
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/20130611/f883fec9/attachment.html>