[LLVMdev] EHABI: Remaining issues (original) (raw)

Logan Chien tzuhsiang.chien at gmail.com
Sat Mar 15 10:06:10 PDT 2014

Hi Renato,

I would like to know what do you mean by "commoning them up"?

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.

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.

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.)

Sincerely, Logan

On Thu, Mar 13, 2014 at 9:15 PM, Renato Golin <renato.golin at linaro.org>wrote:

Hi Keith, Anton, Logan,

Last time we spoke about ARM unwinding, we agreed to have both CFI and directive variants in ARM, so that both EH and debuggers/profilers could correctly unwind the stack. The problem, obviously, is that we now have redundant information and I decided to have a go commoning them up. One of the issues, I think, is GNU compatibility (so GAS can generate the tables correctly when not using the integrated assembler), and it seems there GCC also emits both EHABI directives and Dwarf, so I don't think we'll be able to move away from it. Since this is only relevant in debug/profiling mode, and the only problem is code size, I think this is something we can live with. Do you guys agree with it? Another issue is the usage of EH tables in C code. I believe the consensus is that it may not be the most optimal for never-exceptional code, but it's the safest default option. The only thing remaining is to choose a way to disable them via some flag. As weird as -fno-exceptions sounds for C code, I think we'll have to go with it. Any other ideas? Finally, Keith, do you have some internal EHABI test you can run Clang on? Does any one know of a large, self contained code, that makes heavy use of exceptions? cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140316/023ca15d/attachment.html>

More information about the llvm-dev mailing list