<div dir="ltr"><div>So yes--that would work.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>--EJM</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 7, 2020 at 3:31 PM Modi Mo <<a href="mailto:modimo@fb.com" target="_blank">modimo@fb.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div>
<p class="MsoNormal">If you don’t need to capture more information and can just terminate, you can directly register std::terminate as the personality routine as opposed to __gxx_personality_v0 or __CxxFrameHandler3/4 (Windows) which lets you omit other metadata
 and work cross-platform.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Modi<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12pt;color:black">From: </span></b><span style="font-size:12pt;color:black">llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> on behalf of Everett Maus via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Reply-To: </b>Everett Maus <<a href="mailto:evmaus@google.com" target="_blank">evmaus@google.com</a>><br>
<b>Date: </b>Monday, December 7, 2020 at 12:47 PM<br>
<b>To: </b>"<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject: </b>[llvm-dev] Catching exceptions while unwinding through -fno-exceptions code<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Hey all:<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I wanted to bring up something that was discussed a few years ago around the behavior of exceptions when interacting with code compiled with -fno-exceptions. (In <a href="https://lists.llvm.org/pipermail/llvm-dev/2017-February/109992.html" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2017-February/109992.html</a>
 and <a href="https://lists.llvm.org/pipermail/llvm-dev/2017-February/109995.html" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2017-February/109995.html</a>)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">It's possible to compile (and link/etc.) code with -fexceptions for some compilation units and -fno-exceptions for others.  Unlike the behavior of noexcept (which requires termination), this doesn't have a specified behavior in the C++
 standard as far as I can tell.  However, it can lead to memory leaks & other issues (e.x. with TSAN, it messes up the tracking of the current stack frame).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'd be interested in looking into potentially doing the work to add an option to clang/etc. to terminate when an exception traverses code compiled with -fno-exceptions, instead of simply allowing the unwinder to walk through the stack frame
 & leak memory/etc. (possibly behind a flag?).  This particular issue bit a team I work closely with, and I'd imagine it could be causing subtle issues for other clang users.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'm mostly concerned with solving this on Linux/x86_64, although if there's a way to solve it more generally I'm open to looking into doing that instead.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I /think/ the right place to change this (from the discussions I linked) would be in the LLVM -> assembly layer, adding an appropriate .gcc_except_table for functions that are determined to be unable to throw exceptions (either due to noexcept
 or due to -fno-exceptions). Then the unwinder would find .eh_frame but no entry in the .gcc_except_table and should terminate (via  __gxx_personality_v0).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Am I understanding that correctly?  What's the best way to propose this sort of change to clang? (document/just try to look at putting together a PR/other?)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Alternatively--one other thing that occurred to me is that it could be reasonably cheap to simply add try/catch blocks that report an UBSAN error in all methods that shouldn't be able to throw an exception.  This obviously doesn't fix the
 code-generation problem and would lead to larger binary sizes, but that seems less bad for an UBSAN build in particular.  That would likely meet my needs around wanting a way to automatically detect this behavior/problem, but might not address the more generic
 issue.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">--EJM<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>

</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr">--EJM</div></div>