<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p class="MsoNormal">It depends on the amount of functionality here and how language specific this is. As it stands I don’t think this is C++ specific and could extend to other llvm language targets which makes it a better candidate with compiler-rt. It would be good to flesh out what behavior you want out of the personality function then go from there.</p></blockquote><div><br></div><div>That makes sense.</div><div><br></div><div>I think there's one "must have" behavior and a few "very nice-to-have but not required" behaviors.</div><div><br></div><div>The "must have" for the handler would be "it terminates the program when an exception passes through code compiled with -fno-exceptions, hopefully in a way that can be easily identified as different from a normal/healthy program exit".</div><div><br></div><div>The nice-to-have list is probably longer:</div><div>1. Printing the exception type that was thrown</div><div>2. Recovering the place the exception was thrown /from/ and printing the function name & offset.</div><div>3. Printing the function name that the unwinder reached that led to it exiting.</div><div>4. (Extra fancy/pie in the sky "what I'd want if I were debugging this situation"): printing the full demangled stack to the location the exception was thrown from or the method that led to the exit. </div><div><br></div><div>I expect that (1) requires some language-specific handling (RTTI in C++/etc.), so that'd imply that it might be good to have a libcxxabi implementation even if there's also a compiler-rt version (it looks like this is the case with __gxx_personality_v0 which is defined both in compiler-rt here: <a href="https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/builtins/gcc_personality_v0.c#L172">https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/builtins/gcc_personality_v0.c#L172</a> and in libcxxabi here: <a href="https://github.com/llvm/llvm-project/blob/main/libcxxabi/src/cxa_personality.cpp#L953">https://github.com/llvm/llvm-project/blob/main/libcxxabi/src/cxa_personality.cpp#L953</a></div><div><br></div><div>I also think that possibly (2)/(3)/(4) might require some non-compiler-rt components, but I'm not certain if they would (I haven't dug into what's in compiler-rt in depth quite yet). That may also be reasonable to defer or to have a sanitizer handle.</div><div><br></div><div>--EJM</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 9, 2020 at 12:15 PM Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</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 dir="ltr">Bleh, early send. We'd also have to overcome the issue of functions being nounwind with -fno-exceptions, which means LLVM would optimize those invokes to calls immediately.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 9, 2020 at 12:14 PM Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.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 dir="ltr">Using existing personality functions requires emitting an LLVM IR cleanup around every function when building in this -fterminate-exceptions mode. Then all functions would have IR like this:<div><br></div><div>invoke void @foo(...) unwind to %terminate</div><div>invoke void @bar(...) unwind to %terminate<br></div><div>...</div><div>landingpad cleanup ...</div><div> call void <a class="gmail_plusreply" id="gmail-m_8237566873461586356gmail-m_-5703438076946573767plusReplyChip-1">@myterminate()</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 8, 2020 at 12:56 PM James Y Knight <<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.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 dir="ltr">Why is adding a new personality function useful? Can't you share a single LSDA table for every noexcept function in a TU (both those implicitly noexcept due to -fno-exceptions and for those marked "noexcept")?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 8, 2020 at 1:05 PM Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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 dir="ltr">I would suggest using a custom personality function for this. It will optimize better and be much smaller than using a standard personality function. It saves the LSDA tables.<div><br></div><div>LLVM supports custom personality functions, so only clang changes are required. You could either do something like add a flag to override the EH personality with a custom one, or come up with a new dedicated fno-exceptions termination personality and add it to compiler-rt.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 7, 2020 at 3:31 PM Modi Mo via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">--EJM</div></div>