[llvm-dev] Catching exceptions while unwinding through -fno-exceptions code

[Hubert Tong via llvm-dev]

On Tue, Dec 8, 2020 at 6:52 AM Everett Maus via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> So yes--that would work.
>
> I think for that route, though, it would be probably useful to try to
> output some more information than just std::terminate does. (i.e. that
> would work as a proof of concept, but getting more debug information the
> way you do with noexcept functions or functions without a handler would be
> more user friendly).
>
The user can control what std::terminate does.


>
> The other reason I was hesitant to go that route is that I was worried
> about the impact of that on binary size (as that's... I think 4+ bytes per
> function added for the .gcc_except_table sections, as opposed to just 4
> bytes for the empty section).  That seems fine for a small binary, but
> seems likely to be expensive-to-prohibitive for large binaries/libraries.
>
Not sure how much binary size balances with other concerns, but it sounds
to me that the methods proposed are ones that would result in false
positives where unwinding through the frame would have resulted in no
action even when compiled with exceptions fully on.

Perhaps leaving functions that would otherwise be "transparent" to
exception handling alone is already implied?

If the baseline for the new mode is instead the fully exception-aware one,
then I think one form of the desired functionality (with high granularity
in terms of avoiding false positives) is to:
error on compiling try-blocks,
make cleanup landing pads terminate,
leave noexcept(true) alone,
and, for dynamic exception specifications, call terminate instead of
unexpected.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201208/20fa668a/attachment.html>