<div dir="ltr">Folks,<div><br></div><div>We're having some discussions about the behaviour of exception handling and Dwarf sharing unwind logic, tables, etc. and it seems that the code around it wasn't designed with any particular goal in mind, but evolved (like the EHABI) and now we're seeing the results from it. </div>
<div><br></div><div>The problems below are assuming C vs. C++, but it actually apply to any possibly-exceptional vs. never-exceptional cases.</div><div><br></div><div><br></div><div>1. C vs. C++</div><div><br></div><div>We have two unwind flags: nounwind, which flags functions that can't unwind (leaf, nothrow, etc) and uwtable, which forces generation of the table regardless of nounwind. It seems sensible that C++ code with exceptions enabled should generate the tables for all functions, in case they're called by (or call) external functions. In C we don't want any of that.</div>
<div><br></div><div>GCC seems to never emit tables, and G++ always do, even on C code (.c files, no exception or anything), which is very sensible and in line with my reasoning above. Clang, on the other hand, always generates them. I guess it'll have to figure out what to do based on its impressions on what language is being used to produce similar results.</div>
<div><br></div><div>I believe that emitting the tables on anything that could potentially interact with exceptional code makes sense, but that's clearly a front-end decision. To LLVM, nounwind and uwtables should be absolute:</div>
<div><br></div><div>IF (uwtables)</div><div> IF (nownwind)</div><div> CantUnwind</div><div> ELSE</div><div> Unwind Table</div><div>ELSE</div><div> do nothing</div><div>ENDIF</div><div><br></div><div><br></div><div>
2. .fnstart/.fnend+friends<br></div><div><br></div><div>Another problem is that the emission of unwinding tables (based on .fnstart/.fnend symbols and others) is conditional *only* to the existence (or not) of an exception handling class being loaded (EHABI, Dwarf). Which means that, we can't disable the EH on a per-function basis.</div>
<div><br></div><div>We'll have to change the way these symbols are emitted, at least when using ARMException, so that we can emit the tables and honour the uwtable on a per-function basis.</div><div><br></div><div>Again, this is a requirement for problem 1, but it'd need to be fixed after 3.</div>
<div><br></div><div><br></div><div>3. Unwinding code</div><div><br></div><div>Currently, even when no exception handling are needed, the exception code is used to generate Dwarf unwinding directives (CFI) for the debugger.</div>
<div><br></div><div>Both DwarfCFIException and ARMException inherit from DwarfException, and they are called to do the debug info about the stack unwinding, which is (at least) misplaced. The consensus is that this code should be factored out.</div>
<div><br></div><div>The part that is relevant to this thread is that, today, if -arm-disable-ehabi is requested, ARMException will not be used and we won't have a way of generating debug stack directives, which is wrong.</div>
<div><br></div><div>Factoring out this code is a requirement for the unwinding problem (1), since if we disable EH today, we'll disable Dwarf stack unwinding altogether. But we also need a final solution for problem 4 below before we start.</div>
<div><br></div><div><br></div><div>4. Clang EH control</div><div><br></div><div><div>There are a number of Clang/LLVM options to control exception handling:</div></div><div> * -fno-excetpion (enable/disable EH on C++ mode, off in C mode)</div>
<div> * -fcxx-exception (no idea, is it objC++ specific? does it control tables in any way?)</div><div> * -funwind-tables (forces uwtable attribute?)<br></div><div> * -arm-disable-ehabi (ARM specific bogus flag)</div><div>
<br></div><div>Those options are not always completely exclusive, and they damage different parts of the compilation process (as seen recently on the list), so we need a clear consensus on what each option mean (or should mean), and translate it to the back-end (via function attributes). This would considerably simplify the back-end and help us tackle this refactoring.</div>
<div><br></div><div>My main target for this problem is to have the one true option on the front-ends, and rely only on function attributes on the back-end (including tools like llc). For that, I'd love to be left with -fexception only and infer all the rest from the language / conditions of the code.</div>
<div><br></div><div>Ex:</div><div><br></div><div>IF (C++ mode)</div><div> IF (-fno-exception)</div><div> no uwtable</div><div> no nounwind</div><div> ELSE</div><div> uwtable</div><div> IF (leaf / nothrow)</div>
<div> nounwind</div><div> ENDIF<br></div><div> ENDIF</div><div>ELSE</div><div> no uwtable</div><div> no nounwind</div><div>ENDIF</div><div><br></div><div>My main goal is to get rid of (at least) -arm-disable-ehabi.<br>
</div><div><br></div><div><br></div><div><br></div><div>Finally,</div><div><br></div><div>If you got this far, you're *really* interested in making the exception handling more user/dev friendly in LLVM, so I welcome any critics about the "proposal" above, as well as any explanations of the doubts expressed. I may be wrong about many things, feel free to enlighten me! We may have a lot less work to do, and I'll be happy. ;)</div>
<div><br></div><div>I believe the dependency graph of the solutions are:</div><div><br></div><div>4 -> 3 -> 2 -> 1</div><div><br></div><div>So, we first should solve the flags problem, than refactor the unwinding code out of EH, make the debug generation use them as well, and then we can start with the EH specific changes. The problem is that 4 will change things considerably, so we might need some scaffolding during the whole process.</div>
<div><br></div><div>Makes sense?</div><div><br></div><div>cheers,</div><div>--renato</div><div><br></div></div>