<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 6 February 2014 18:02, Keith Walker <span dir="ltr"><<a href="mailto:Keith.Walker@arm.com" target="_blank">Keith.Walker@arm.com</a>></span> wrote:<br>
<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 class="im"><span style="color:rgb(34,34,34)">You can make GCC emit unwind tables for C if you use the command line option -funwind-tables.</span><br>
</div>
<br>
This could be useful if you are compiling C code which is called by C++ code and which itself calls C++ code and you wish the C++ exception to propagate through the C code.<br></blockquote><div><br></div><div>Yes, we still need the possibility to force unwind tables in C code, and that's what -funwind-tables is there for.</div>
<div><br></div><div>Since -fexception only triggers landing pads and cleanup blocks, we don't need to worry about it, but the -funwind-tables should communicate with the back-end via some clear and unambiguous means.</div>
<div><br></div><div>Maybe function attributes aren't enough, but we need to make sure that they don't clash with the flags, if we do use 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 class="im"><span style="color:rgb(34,34,34)">There is some interaction in that if you are generating a .eh_frame section for exception handling then there is little sense is generating a DWARF .debug_frame section as well; I would hope most debuggers could use the .eh_frame section if present as its format is so similar to a .debug_frame section.</span></div>
</blockquote><div><br></div><div>Right, makes sense.</div><div><br></div><div>It seems, then, that we basically need two types of unwinding, and they could live in different places. </div><div><br></div><div>Before your patch, the debugger wasn't able to use the EHABI stack unwinding code. Is that because it was using .push/.save instead of .cfi directives? Or is that because the table generated is not readable by normal debuggers?</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 class="im"><span style="color:rgb(34,34,34)">What does -arm-disable-ehabi actually mean?</span><br>
</div>
<br>
Currently it is effectively "don't generate exception tables".<br></blockquote><div><br></div><div>Yes. It has no effect on the front-end. It should actually be replaced by whatever mechanism -f{no-}unwind-tables is using.</div>
<div><br></div><div>I created a bug (PR18758) and copied you.</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">
Maybe is should it rather be "don't generate EHABI exception tables but generate .eh_frame tables instead"? Obviously this requires the necessary DWARF like support to generate the information for the .eh_frame tables.<br>
</blockquote><div><br></div><div>This is where things start getting a little interesting. If we all agree that generating unwind tables is good *in any case*, even on embedded devices like Coretx-M0, than I think we should hard-code .eh_frame generation under any circumstance, and use -funwind-tables to generate EHABI tables.</div>
<div><br></div><div>Clang would then enable it by default depending on the language contract, which is of little importance to the back-end.</div><div><br></div><div>But the question I don't have an answer yet is: if we use that flag, what do we do when -fno-unwind-tables clashes with the uwtables function attribute?</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 class="im"><span style="color:rgb(34,34,34)"> IF(arm_disable_ehabi)</span><br>
</div>
USE ARMException<br>
ELSE<br>
USE DwarfCFIException<br>
ENDIF<br></blockquote><div><br></div><div>Today, it means:</div><div><br></div><div>IF(arm_disable_ehabi)<br></div><div> nothing at all</div><div>ELSE</div><div> USE ARMException</div><div>ENDIF</div><div><br></div><div>
I'm sensing that the consensus is driving towards *always* emitting unwind tables, but I can't just use DwarfCFIException on ARM, it won't work. This is why we need to carefully extract the common interface, not just for the debug x EH problem, but also the Dwarf x EHABI problem.</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><div class="h5"><span style="color:rgb(34,34,34)">Hmmm! I'm very nervous about the backend making decisions based on the language.</span><br></div></div></blockquote><div><br></div><div>No, sorry! That was a front-end decision! I'd die before enquiring the language in the back-end! :D</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"> IF (-funwind-tables || -fexceptions)<br>
<div class="im"> uwtable<br>
IF (leaf / nothrow)<br>
nounwind<br>
ENDIF<br>
</div><div class="im"> ELSE<br>
no uwtable<br>
no nounwind<br>
ENDIF<br></div></blockquote><div><br></div><div>I'd only like to completely remove the unwind tables if the user forcefully selected -fno-unwind-tables, so I wouldn't like Clang to automatically select that, even in C code.</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">-fexceptions allows compiling exception handling constructs in the source language and enables the generation of unwind tables.<br>
-funwind-tables only enables the generation of unwind tables.<br></blockquote><div></div></div><br></div><div class="gmail_extra">That makes total sense. Right now, I can't see a difference between -fno-unwind-tables and -arm-disable-ehabi.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">As far as I could see, -fcxx-exceptions has no relevance to this discussion, so I'll drop it right here.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
My questions about the flags were answered, and it's going to be a lot easier than I thought. I'll change the ehabi flag to connect via unwind-tables and will send a patch review. </div><div class="gmail_extra"><br>
</div><div class="gmail_extra">Once that's done, we can get some work done on refactoring ARMException, but only after your patch lands upstream.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks!</div>
<div class="gmail_extra">--renato</div></div>