<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 6 February 2014 19:21, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">if (nounwind)</div><div class="gmail_quote">  can't unwind</div></div></div></blockquote><div><br></div><div>can't unwind == unwind table + no EH directives + no EH table</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">if (uwtable || (!nounwind && need uwtable to unwind))<br></div><div class="gmail_quote">  unwind table</div></div></div></blockquote><div><br></div><div>"need unwind table to unwind" is probably true in almost all cases. At least in all where ARMException and DwarfCFIException are concerned, which is the ones we're discussing about.</div>
<div><br></div><div>I'm beginning to think that there is no reason at all to have an uwtable attribute, given that the -funwind-tables is propagated to the back-end AND if we emit the table for one function we should do it for all.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div>I believe the intent is:</div><div>  -fexceptions/-fno-exceptions controls whether we generate code that copes with exceptions passing through it.</div></div></div></div></blockquote><div><br>
</div><div>Right. Landing pads, cleanups, etc. We'll need those for emitting the EH tables, but not the unwind tables, so for this particular discussion, we don't need to worry.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>  -fcxx-exceptions/-fno-cxx-exceptions controls whether we allow exception constructs in C++ code (throw, catch, try) and whether we validate exception specifications (both during compilation and at runtime).</div>

<div>  -fobjc-exceptions/-fno-objc-exceptions controls whether we allow exception constructs in ObjC code (@throw, @try, @catch).</div></div></div></div></blockquote><div><br></div><div>Language-specific stuff, not even important to the EH tables (since in the back end we don't care what constructs you use in the language, only the IR basic block structure).</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div>  -fno-exceptions implies -fno-cxx-exceptions and -fno-objc-exceptions<br></div>
<div>  -fcxx-exceptions and -fobjc-exceptions require -fexceptions</div></div></div></div></blockquote><div><br></div><div>Will -fcxx-exceptions also include -fexceptions? I mean, if the user specify -fcxx-exceptions in C, will that also turn on all the internal flags that -fexception would?</div>
<div><br></div><div>If so, we really don't need to worry at all about them.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>-funwind-tables appears to be an entirely orthogonal flag, which is by default determined based on the target (with some -f flags to override the default), entirely ignoring the -fexceptions flags and language mode.</div>
</div></div></div></blockquote><div><br></div><div>Right. They do clash in the back-end, since one generates EH unwinding and the other might only generate Dwarf unwinding. We need to clear that confusion in the back-end, but I don't think that the front-end should even care on how it gets implemented in the end, as long as it works.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div>This does not appear to be a flag that an end-user should touch, under most circumstances, but it's far from clear to me that we're getting the default right here (maybe it should depend on -fexceptions?).<br>
</div></div></div></div></blockquote><div><br></div><div>I think that both -fexceptions and -g should turn -funwind-tables by default. The third user is the backtrace which doesn't need debug or EH info (just the unwind table), and you need the -funwind-tables IFF your target doesn't have it on by default.</div>
<div><br></div><div>I can only think about GPU targets that won't need any of that, but they're not using Dwarf or EHABI handlers, so we shouldn't concern about that. Embedded CPUs might want them disabled to save space, and for that we should actively disable (-fno-unwind-tables or -Os/z).</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div></div>
<div>The 'nounwind' attribute is set if -fexceptions is specified, or if we have some other way of knowing the function does not throw.</div></div></div></div></blockquote><div><br></div><div>You mean -fno-exceptions, I believe. I think this behaviour is correct.<br>
</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div>The 'uwtable' attribute is set based on the value we determined for -funwind-tables (either through an explicit flag or from the target).<br></div></div></div></div></blockquote><div>
<br></div><div>Seems reasonable, though unnecessary in most cases.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>This seems wrong -- in C with -fexceptions we do not want nounwind, and sometimes want uwtable (depending on ABI).</div></div></div></div></blockquote>
<div><br></div><div>Yes, I agree, I was wrong. Unwind tables are almost entirely orthogonal to EH and Dwarf.</div><div></div></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks everyone for the enlightening responses, I'll have to digest everything again and see if I remember any of it tomorrow... :)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I managed to get a definite step out of this (<a href="http://llvm.org/PR18758">http://llvm.org/PR18758</a>), and I think we can safely ignore the -fexceptions flags for now.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">My revised plan:</div><div class="gmail_extra"><br></div><div class="gmail_extra">0. Get Keith's patch in to have unwinding without EH</div><div class="gmail_extra">
1. Connect -funwind-tables with EHABI</div><div class="gmail_extra">2. Abstract the unwind code where both EH and the Dwarf producers can make use of</div><div class="gmail_extra">3. Disable unwind tables if -fno-unwind-tables on ARM</div>
<div class="gmail_extra">4. Apply CFI unwinding if -funwind-tables AND -fno-exceptions on EHABI</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm not sure why we're using .save/.push and not CFI with EHABI, but step 2 would be a lot simpler if we could unify both exception handling classes, and step 4 would completely disappear. Anton/Logan?</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">cheers,</div><div class="gmail_extra">--renato</div></div>