<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 26 Jan 2021, at 10:25, Ilia K wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Hi!<br>
<br>
It turned out that I cannot catch `std::bad_alloc&` thrown by the `operator<br>
new` when compiling 1.cpp with -fno-rtti and linking against system's<br>
libc++.1.dylib/libc++abi.dylib on macOS. This scenario works on Linux, and<br>
according to the official libc++ page it is supported ("However linking<br>
against it with -fno-rtti is supported", <a href="https://libcxx.llvm.org/" style="color:#777">https://libcxx.llvm.org/</a>), however<br>
the following code is aborted due to an unhandled exception:<br>
<br>
```1.cpp<br>
#include <cstdio><br>
#include <new><br>
<br>
int main() {<br>
try {<br>
::operator new(-1);<br>
} catch (std::bad_alloc& e) {<br>
printf("caught %s\n", e.what());<br>
}<br>
return 0;<br>
}<br>
```<br>
<br>
Compile & run:<br>
```<br>
$ clang++ -fno-rtti 1.cpp -o 1_no_rtti<br>
$ ./1_no_rtti<br>
libc++abi.dylib: terminating with uncaught exception of type<br>
std::bad_alloc: std::bad_alloc<br>
Abort trap: 6<br>
```<br>
<br>
I know about similar issues with exceptions when -fno-rtti on macOS<br>
(Polymorphically catching an exception in a -fno-rtti shared library on Mac<br>
OS X<br>
<a href="https://stackoverflow.com/questions/3638237/polymorphically-catching-an-exception-in-a-fno-rtti-shared-library-on-mac-os-x" style="color:#777">https://stackoverflow.com/questions/3638237/polymorphically-catching-an-exception-in-a-fno-rtti-shared-library-on-mac-os-x</a>,<br>
Problems throwing and catching exceptions on OS X with -fno-rtti<br>
<a href="https://stackoverflow.com/questions/21737201/problems-throwing-and-catching-exceptions-on-os-x-with-fno-rtti" style="color:#777">https://stackoverflow.com/questions/21737201/problems-throwing-and-catching-exceptions-on-os-x-with-fno-rtti</a>).<br>
There was an issue in Android NDK with exceptions when -flto=thin and it<br>
was said that "The problem is that we have multiple copies of a symbol,<br>
where one of them is strong, and the others are linkonce_odr"<br>
<a href="https://github.com/android/ndk/issues/1046#issuecomment-514469559" style="color:#777">https://github.com/android/ndk/issues/1046#issuecomment-514469559</a> (fixed<br>
now <a href="https://reviews.llvm.org/D61255" style="color:#777">https://reviews.llvm.org/D61255</a>).<br>
<br>
Can anyone shed some light on it? It seems like a bug at the moment, and if<br>
your code uses any of libc++.1.dylib/libc++abi.dylib system libraries on<br>
macOS, you must leave RTTI enabled, except you have turned exceptions off<br>
as well.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">Mechanically, the problem here is that exceptions rely on RTTI, so<br>
combining <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">-fno-rtti</code> with <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">-fexceptions</code> forces the compiler to make<br>
an awkward decision about whether to expect that classes with key<br>
functions emit their RTTI objects eagerly. If the compiler trusts<br>
classes to do this, then you can’t catch and throw exceptions of your<br>
own class types that happen to have key functions; if the compiler<br>
doesn’t trust classes to do this, then you can’t catch and throw<br>
exceptions of system classes like <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">std::bad_alloc</code> (or any class that<br>
happens to have a key function and is compiled with RTTI enabled).<br>
The traditional decision is to favor the first, and we can’t really<br>
change that.</p>
<p dir="auto">Darwin is stricter about RTTI object matching than other platforms,<br>
and we’re also not going to change that.</p>
<p dir="auto">Ultimately, <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">-fno-rtti -fexceptions</code> is only a semi-supported<br>
configuration. It causes language implementation problems which it<br>
becomes your responsibility to work around. In this case, you can do<br>
that by catching the exception in a file that does not disable RTTI.</p>
<p dir="auto">John.</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">FYI, the difference between non-RTTI (./1_no_rtti) and the default<br>
(./1_rtti, with RTTI) Mach-O executables:<br>
```<br>
$ diff <(nm -C 1_no_rtti) <(nm -C 1_rtti)<br>
1c1<br>
< 0000000100003f48 s GCC_except_table0<br>
---</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">0000000100003f68 s GCC_except_table0</p>
</blockquote><p dir="auto">4,9c4<br>
< 0000000100004028 S typeinfo for std::bad_alloc<br>
< 0000000100004018 S typeinfo for std::exception<br>
< 0000000100003f74 S typeinfo name for std::bad_alloc<br>
< 0000000100003f81 S typeinfo name for std::exception<br>
< U vtable for __cxxabiv1::__class_type_info<br>
< U vtable for __cxxabiv1::__si_class_type_info<br>
---</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto"> U typeinfo for std::bad_alloc</p>
</blockquote><p dir="auto">11c6<br>
< 0000000100003ed0 t ___clang_call_terminate<br>
---</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">0000000100003ef0 t ___clang_call_terminate</p>
</blockquote><p dir="auto">17c12<br>
< 0000000100003e20 T _main<br>
---</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">0000000100003e40 T _main</p>
</blockquote><p dir="auto">$ diff <(clang++ -fno-rtti 1.cpp -S -o -) <(clang++ 1.cpp -S -o -)<br>
143,169d142<br>
< .section __TEXT,__const<br>
< .globl __ZTSSt9bad_alloc ## @_ZTSSt9bad_alloc<br>
< .weak_definition __ZTSSt9bad_alloc<br>
< __ZTSSt9bad_alloc:<br>
< .asciz "St9bad_alloc"<br>
<<br>
< .globl __ZTSSt9exception ## @_ZTSSt9exception<br>
< .weak_definition __ZTSSt9exception<br>
< __ZTSSt9exception:<br>
< .asciz "St9exception"<br>
<<br>
< .section __DATA,__const<br>
< .globl __ZTISt9exception ## @_ZTISt9exception<br>
< .weak_definition __ZTISt9exception<br>
< .p2align 3<br>
< __ZTISt9exception:<br>
< .quad __ZTVN10__cxxabiv117__class_type_infoE+16<br>
< .quad __ZTSSt9exception<br>
<<br>
< .globl __ZTISt9bad_alloc ## @_ZTISt9bad_alloc<br>
< .weak_definition __ZTISt9bad_alloc<br>
< .p2align 3<br>
< __ZTISt9bad_alloc:<br>
< .quad __ZTVN10__cxxabiv120__si_class_type_infoE+16<br>
< .quad __ZTSSt9bad_alloc<br>
< .quad __ZTISt9exception<br>
<<br>
```<br>
<br>
Linked issues: <a href="https://reviews.llvm.org/D46665" style="color:#777">https://reviews.llvm.org/D46665</a>,<br>
<a href="https://reviews.llvm.org/D47092" style="color:#777">https://reviews.llvm.org/D47092</a>,<br>
<a href="https://reviews.llvm.org/rG2405bd6898151e0a7ffede78b0d0c7c85c0b66d3" style="color:#777">https://reviews.llvm.org/rG2405bd6898151e0a7ffede78b0d0c7c85c0b66d3</a>,<br>
<a href="https://github.com/Amanieu/asyncplusplus/commit/2360c8993951afab67ab0414288dacae1dbd7195" style="color:#777">https://github.com/Amanieu/asyncplusplus/commit/2360c8993951afab67ab0414288dacae1dbd7195</a><br>
<br>
-- <br>
- Ilia</p>
</blockquote></div>
<div style="white-space:normal">
</div>
</div>
</body>
</html>