<div dir="ltr"><div><div>Hi Renato,<br><br></div>I would like to know what do you mean by "commoning them up"?<br><br>I object to the idea to remove (or reduce) the ARM directives in favor of CFI directives, though I believe it will be good to emit *both* ARM directives and CFI directives so that some debugger or profiling tools can be used without implementing ARM-specific logic.<br>
<br></div>The main reason for the objection is the compatibility between the integrated-as and the binutils gas.  What if we have to use gas to compile the output of LLVM?  Although we are working hard to improve the integrated-as, but there are a lot of existing code simply doesn't work when integrated-as is used.  Some of the issues are even considered as a *feature* and marked as won't fix.<br>
<div><br></div><div>For the space issue, I personally don't think this is a big issue.  For the code without exception handling, only stack informations will be encoded.  Besides, the encoding format is very compact.  In the common cases, the code without exception handling needs only 8-12 bytes per function.  If this is still an issue, then -fno-unwind-table might be a solution (i.e. at llvm assembly level, the function should be marked with nounwind and without uwtable.)<br>
</div><div><br></div><div>Sincerely,<br>Logan<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 9:15 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Keith, Anton, Logan,<br>
<br>
Last time we spoke about ARM unwinding, we agreed to have both CFI and<br>
directive variants in ARM, so that both EH and debuggers/profilers<br>
could correctly unwind the stack. The problem, obviously, is that we<br>
now have redundant information and I decided to have a go commoning<br>
them up.<br>
<br>
One of the issues, I think, is GNU compatibility (so GAS can generate<br>
the tables correctly when not using the integrated assembler), and it<br>
seems there GCC also emits both EHABI directives and Dwarf, so I don't<br>
think we'll be able to move away from it. Since this is only relevant<br>
in debug/profiling mode, and the only problem is code size, I think<br>
this is something we can live with. Do you guys agree with it?<br>
<br>
Another issue is the usage of EH tables in C code. I believe the<br>
consensus is that it may not be the most optimal for never-exceptional<br>
code, but it's the safest default option. The only thing remaining is<br>
to choose a way to disable them via some flag. As weird as<br>
-fno-exceptions sounds for C code, I think we'll have to go with it.<br>
Any other ideas?<br>
<br>
Finally, Keith, do you have some internal EHABI test you can run Clang<br>
on? Does any one know of a large, self contained code, that makes<br>
heavy use of exceptions?<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div><br></div>