[llvm-bugs] [Bug 26739] New: clang does not remove FDEs for zero-sized functions which breaks exceptions

[via llvm-bugs]

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

            Bug ID: 26739
           Summary: clang does not remove FDEs for zero-sized functions
                    which breaks exceptions
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: egor.kochetov at intel.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Currently clang produces no assembly code for non-void functions without any
code inside (if using at least -O1). Definitely, calling such functions is UB
in C++, but this also has some side effects. In particular, these functions'
address range is zero that sometimes breaks exception handling.

Supposed solution is: remove FDE for the functions that are shrunk to zero
length. The details and rationale are below.

Consider the following source:

int f() {}
int main () {
  try {
    throw 1;
    return 1;
  } catch (int) {
    return 0;
  }
  return 2;
}

When the exception is thrown, then the runtime unwinder looks for the correct
stack frame information (FDE), and actually finds two of these: for the
function f and for main, both starting at the same address. Since normally no
two functions share the same starting address, only one of these FDEs is used,
and if we are unlucky, the unwinder chooses the FDE for the function f and the
exception misses the 'catch'.

The real test case which is broken because of this is here:
https://android.googlesource.com/platform/ndk/+/master/tests/device/test-stlport_static-exception/jni/dyncast2_1.cpp.
It is broken if using clang++ with gold linker, stlport c++ library statically
linked, and the unwinder from libgcc.a

Supposed solution is: remove FDE for the functions that are shrunk to zero
length since such functions can actually never throw an exception and need no
stack unwinding information.

To see the issue reproduced, you can compile the source above using 'clang++
-c' and examine the result with 'readelf -wf'. There will be a potentially
faulty entry with 'pc=00000000..00000000' followed by the entry for 'main' with
the same starting address.

-- 
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/20160225/0ca0b77d/attachment.html>