llvm dev - Sep 2010 - [LLVMdev] Any plans to add LLVM support for ARM EH EABI ?

On Mon, Sep 27, 2010 at 09:14:05AM -0700, Jason Kim
wrote:
> On Mon, Sep 27, 2010 at 8:50 AM, Dennis Taul <dtaul at
codeaurora.org> wrote:
> >
> > I am new to LLVM but have perused the code alongside using llvm-gcc
> > and CLANG to build ARM EABI objects.
> >
> > Based on this superficial analysis it appears that LLVM currently does
> > not support the ARM Exception Handling ABI (as defined under the
> > EABI).
> >
> > Can anyone comment on whether plans are in place to remedy this?
> > I did see the discussion regarding work on the MC for ARM. Will this
> > work include emitting the exception handling code/tables compliant to
> > ARM's EH ABI?
> 
> Probably not at first. It may require discussions with the specific
> front end folks (clang, llvm-gcc et al).
> 
> Thanks for bringing it up tho.,
> 
Thanks Jason. 

Is it safe to say the MC work provides a (new) foundation for
implementing ARM EH? Or, is providing ARM EH independent of the ARM-MC
work?
> >
> > Thanks,
> >
> > -Dennis
> >
> >

> Is it safe to say the MC work provides a (new) foundation for
> implementing ARM EH? Or, is providing ARM EH independent of the ARM-MC
> work?
The latter. MC stuff helps somehow though.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

On 27 September 2010 18:44, Anton Korobeynikov <anton at
korobeynikov.info> wrote:
>> Is it safe to say the MC work provides a (new) foundation for
>> implementing ARM EH? Or, is providing ARM EH independent of the ARM-MC
>> work?
> The latter. MC stuff helps somehow though.
Hi Anton,

What would be the best way to go on implementing EHABI exceptions in MC?

I got LLVM to lower the tables in the correct sections by changing
ARMMCAsmInfo and ARMISelLowering and LoweringObjectFile, but the
format is completely different and the personality routines get lost.
I could spend some time making it fit in DwarfException, but that's
clearly the wrong way...

I've noticed that DwarfException is using AsmPrinter directly, which
uses MCStreamer and, supposedly, can print ASM and Obj formats. But
there is no way to override that (say, by creating a ARMException
class, derived from the same parent class) and add it to AsmPrinter.

  if (MAI->doesSupportExceptionHandling())
    DE = new DwarfException(this);

Not only the object is private, there's no way to set it, and it's
called DwarException when it actually lowers both Dwarf and SjLj
modes. I propose a change to make ExceptionHandling a virtual class,
with DwarfException, SjLjException and ARMException deriving from it,
and the choice to create the DE object (above) be on the exception
type that is already in MCAsmInfo.

  ExceptionHandling* EH;
  switch (MAI->getExceptionHandlingType()) {
  case ExceptionHandling::SjLj:
    EH = new SjLjException(this); break;
  case ExceptionHandling::Dwarf:
    EH = new DwarfException(this); break;
  case ExceptionHandling::ARM:
    EH = new ARMException(this); break;
  }


Also, TargetLoweringObjectFile assumes the sections are *always*
called "gcc_except_table" and "eh_frame", which is clearly
not true in
EHABI. That should also be extended to work across different ABIs, so
ARMException would get the correct sections. (should be easy just to
add new sections, though).

Does this make sense?

-- 
cheers,
--renato

PS: Shouldn't AsmPrinter be called MCPrinter now?