[LLVMdev] ARM EABI Exceptions

Jim Grosbach grosbach at apple.com
Wed May 19 09:03:20 PDT 2010


On May 19, 2010, at 2:37 AM, Renato Golin wrote:

>> -----Original Message-----
>>> My main concern is that DwarfException is not extensible at all. I
>>> can't inherit from it (DwarfWriter creates it directly) and there are
>>> no call backs to target-specific code (nor registration of such
>>> mechanism).
>> 
>> Why do you need this? My feeling that this will not be required. I
>> might be mistaken though.
> 
> Hi Anton,
> 
> Maybe I'm following the wrong path, then.
> 
> When trying to make llc print the EH table for clang-compiled IR, I noticed that there was none. If I turn on the Dwarf exception in ARMMCAsmInfo, I could see a table that looks like GCC's. ARM EHABI tables are quite different and the idea is not to produce them now, but to make clang generated asm/objects to be compiled/linked with arm-none-eabi-gcc.
> 
> In that area, I was trying to make LLVM DwarfException more like GCC's, and for that I had to make some changes in the order things appear (the table is inside the function instead of in a new section, thus the size has to appear after the table), and add new things (.fnstart, .fnend, .personality, etc), and make sure all Actions are in conformance with GCC's intrinsics. Also, looks like gcc doesn't produce the CIE nor any of the FDEs, so maybe I have to suppress that as well. 
> 
> For all those changes, the only place I can implement, AFAIK, is DwarfException. Now, as a local hack, I have added a new ExceptionABI { None, ARM }; enum to MCAsmInfo to if/else inside DwarfException, but that's far from ideal. 
> 
> I'd like to be able to have with DwarfException the same we have with AsmPrinter, calling target-implemented functions (like EmitFunctionBodyStart, etc), so one could customise the particular differences of a target. But this change is a bit wide-spread, since DwarfWriter will also have to be changed to create a target-specific exception writer rather than the generic one.
> 
> But again, maybe the whole thing is pointless, and clang already generates exception tables compatible with eabi-gcc and I was not able to make it work.
> 

It's likely there will be some work to get DWARF EH working for ARM. That said, keep in mind that the goal is to get the code to conform to the ABI, not to produce code and tables that look the same as what GCC produces. The former is reasonable, the latter is going to feel like tilting at windmills, as the internal EH representations in gcc are very different than what llvm IR represents. GCC uses a side-table of EH "regions" that it references to determine call sites and such, for example. LLVM doesn't have that concept and uses the invoke instruction instead. One result of this is that the tables that come out often look quite different. So long as they adhere to the spec, though, the code will interoperate correctly.

Regards,
  Jim



More information about the llvm-dev mailing list