<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">I am in favor of doing things the way MSVC does it (for now). I ask that you try not to design out what I’m pitching to the C++ standards committee:<o:p></o:p></p>
<p class="MsoNormal">Leaving no room for a lower-level language: A C++ Subset<o:p></o:p></p>
<p class="MsoNormal"><a href="http://wg21.link/p1105">http://wg21.link/p1105</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The polls that I’ve had on that leaned towards having a throw call go to std::terminate.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> cfe-dev <cfe-dev-bounces@lists.llvm.org> <b>On Behalf Of
</b>Reid Kleckner via cfe-dev<br>
<b>Sent:</b> Thursday, September 27, 2018 1:48 PM<br>
<b>To:</b> kristina@nym.hush.com<br>
<b>Cc:</b> cfe-dev <cfe-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [cfe-dev] [RFC][C++]: Option to emit a run-time call when throw statement is used with `-fno-exceptions` instead of diagnosing an error.<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Would it be enough to just emit the code to implement the throw anyway, and let the user provide their own implementation of the C++ EH runtime that terminates the program?<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
That's what we already do when we encounter `throw` in a system header. Consider this example:<o:p></o:p></p>
</div>
<div>
<pre id="gmail-hterm:copy-to-clipboard-source"><span style="color:black">$ cat asdf/t.h<o:p></o:p></span></pre>
<pre><span style="color:black">inline void f() {<o:p></o:p></span></pre>
<pre><span style="color:black"> throw 0;<o:p></o:p></span></pre>
<pre><span style="color:black">}<o:p></o:p></span></pre>
<pre><span style="color:black"><o:p> </o:p></span></pre>
<pre><span style="color:black">$ cat t.cpp<o:p></o:p></span></pre>
<pre><span style="color:black">#include "t.h"<o:p></o:p></span></pre>
<pre><span style="color:black">int main() {<o:p></o:p></span></pre>
<pre><span style="color:black"> f();<o:p></o:p></span></pre>
<pre><span style="color:black">}<o:p></o:p></span></pre>
<pre><span style="color:black"><o:p> </o:p></span></pre>
<pre id="gmail-hterm:copy-to-clipboard-source"><span style="color:black">$ clang -S t.cpp -fno-exceptions -isystem asdf -o - | grep cxa<o:p></o:p></span></pre>
<pre><span style="color:black"> callq __cxa_allocate_exception<o:p></o:p></span></pre>
<pre><span style="color:black"> callq __cxa_throw<o:p></o:p></span></pre>
<p class="MsoNormal">Alternatively, we could pursue a model more like MSVC, where /EHs- just turns off C++ destructor cleanups, which eliminates all implicit EH costs. You can use 'throw' and 'try', but since no cleanups will run, you can't reasonably recover
from an exception. It just gives you an opportunity to end the program in an appropriate way.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Another reasonable model would be to compile try/catch to nothing, to guarantee that the first throw will end the program.<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Sep 27, 2018 at 2:47 AM via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">The current behavior of `throw <object-instance>` is to diagnose it as a hard error<br>
unless it's in a system header. This makes integrating codebases that use exceptions<br>
difficult without resorting to macro tricks and alike. <br>
<br>
The proposal is to add a driver option to allow the compiler to turn such cases into<br>
runtime calls to a function like `__cxa_throw_noexcept(...)` stepping into another<br>
frame, with the opaque handle pointing to the exception that would be thrown in that<br>
case. This is more flexibile than std::terminate() approaches as it allows the <br>
application vendor to define such function in their code (if the driver flag is<br>
enabled) and implement a more graceful failure (ie. symbolicated stack trace) without<br>
the need to change existing code.<br>
<br>
Rationale is that is makes large codebases compiled include components that make use<br>
of throw without splitting them into separate archives, in source form requires<br>
changing the code throwing the exceptions which is not always easy to merge back into<br>
an upstream project. This also opens the possibility of a less vague variant of such<br>
ABI function if RTTI data is enabled but exceptions are disabled where the application<br>
can implement custom logic for handling specific types of objects.<br>
<br>
Majority of cases would still require termination but this option allows existing code<br>
to compile with exceptions disabled and without having to maintain downstream forks<br>
of various projects because they use exceptions. In such cases the application is free<br>
to decide what to do without the need for any refactoring and while this opens up room<br>
for fairly dangerous errors, this assumes that whoever is using that compiler flag is<br>
aware of exception basics and that such an ABI function cannot resume execution normally,<br>
it is better to allow the author to decide how to handle the case (ie. crash dump, signal,<br>
call continuation or any other form of context switch). With or without RTTI such a<br>
function could also include source context of the throw in case where exceptions are<br>
fatal and source/location data is desired in the crash report.<br>
<br>
If such flag is enabled, it is up to the application to provide an implementation<br>
of `__cxa_throw_noexcept` dealing with that behavior which also acknowledges that the<br>
author understands the semantics of it (ie. the current frames are likely trashed, there<br>
may be lock guards held, which would have to be accounted for somehow). The proposal<br>
is aimed at environments with a alternative standard library which may do this accounting<br>
in application defined fashion such as storing non-critical (non-spinlocks) locks inside<br>
a thread control block, in which case such cases could even be considered recoverable<br>
giving `throw` an opportunity to exist even in embedded environments.<br>
<br>
Thank you.<br>
- Kristina<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=tSmf-6PTbDaz8_gTHJyr62hN2CnP7G1gLLQ60LXatS0&s=BQ4l2u8kdGGWB4U5ntx-Aw81WWJ5f9ZGIXRZMAJJo9w&e=" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>