[libcxx-dev] [cfe-dev] Exception handling with RTTI disabled on macOS

Ilia K via libcxx-dev libcxx-dev at lists.llvm.org
Tue Jan 26 09:03:01 PST 2021


Unfortunately, there is no description for -fno-rtti flag on
https://releases.llvm.org/11.0.0/tools/clang/docs/ClangCommandLineReference.html
but I assume it should work the same as in GCC:
> Disable generation of information about every class with virtual
functions for use by the C++ runtime type identification features
(`dynamic_cast' and `typeid'). If you don't use those parts of the
language, you can save some space by using this flag. Note that exception
handling uses the same information, but it will generate it as needed.

So it looks like in G++ we can use -fno-rtti, but the compiler will still
generate it if needed. Is it true for Clang on macOS? If not, then what
about Linux?

I also found the -fno-rtti-data option, without description as well.

On Tue, Jan 26, 2021 at 6:44 PM Marshall Clow <mclow.lists at gmail.com> wrote:

> [ removing cfe-dev]
>
> On Jan 26, 2021, at 7:25 AM, Ilia K via cfe-dev <cfe-dev at lists.llvm.org>
> wrote:
>
>
> Hi!
>
> It turned out that I cannot catch `std::bad_alloc&` thrown by the
> `operator new` when compiling 1.cpp with -fno-rtti and linking against
> system's libc++.1.dylib/libc++abi.dylib on macOS. This scenario works on
> Linux, and according to the official libc++ page it is supported ("However
> linking against it with -fno-rtti is supported", https://libcxx.llvm.org/),
> however the following code is aborted due to an unhandled exception:
>
> ```1.cpp
> #include <cstdio>
> #include <new>
>
> int main() {
>     try {
>         ::operator new(-1);
>     } catch (std::bad_alloc& e) {
>         printf("caught %s\n", e.what());
>     }
>     return 0;
> }
> ```
>
> Compile & run:
> ```
> $ clang++ -fno-rtti 1.cpp -o 1_no_rtti
> $ ./1_no_rtti
> libc++abi.dylib: terminating with uncaught exception of type
> std::bad_alloc: std::bad_alloc
> Abort trap: 6
> ```
>
>
>
> That sounds right to me.
> If you don’t have RTTI, then the catch mechanism cannot match up the type
> of the exception and the type that you’re looking to catch.
> You should be able to catch (…), though.
>
> — Marshall
>


-- 
- Ilia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20210126/945e7909/attachment.html>


More information about the libcxx-dev mailing list