This is an archive of the discontinued LLVM Phabricator instance.

Enable EHABI by default on non-Darwin ARM targets
ClosedPublic

Authored by rengolin on Jan 27 2014, 8:26 AM.

Details

Reviewers
rengolin
asl
Summary

After all hard work to implement the EHABI and with the test-suite passing, it's time to turn it on by default and allow users to disable it as a work-around while we fix the eventual bugs that show up.

This commit also remove the -arm-enable-ehabi-descriptors, since we want the tables to be printed every time the EHABI is turned on for non-Darwin ARM targets.

Current EH test in the test-suite pass with these changes, so a follow-
up commit on the test-suite will re-enable them.

The only problem is that MCJIT can't handle some new relocation, so would be good to disable EHABI while JIT-ing, but I have no idea how. Most (all?) MCJIT tests fail with this commit, so we need to either disable that or fix it. I'd rather disable to get to work on it in separate, since static compilation is working well.

Not implemented relocation type!
UNREACHABLE executed at /home/user/devel/llvm/src/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:482!

Diff Detail

Event Timeline

asl added a comment.Jan 27 2014, 8:59 AM

Maybe we temporary keep the option, but make it enabled by default? So MCJIT users can switch it off until missed relocs support will be added?

Hi Anton,

I kept the option as "-arm-disable-ehabi", but requiring all MCJIT users to start using them would be cheeky. Meanwhile, I'll have a look at which relocation is missing and try to implement it, but that might not be the only problem and I could spend a huge time chasing the wrong problem.

The main issue with the MCAsmInfo is that there is no way to turn it on/off dynamically (only based on that flag and being ELF), so another possibility would be to add a dynamic disableEH() and call it from MCJIT's drivers. I'll do this one first and add to this commit and chase the relocation later. We should be able to remove this method once everything works fine for a while.

I traced back the problems on MCJIT:

  1. two relocations needed recognizing (NONE, PREL31), which could easily be implemented by ignoring NONE and matching PREL31 with existing similar relocations (I need to make sure this is right)
  2. tests failing should have nounwind on them, since there's nothing about EH on any of them. We should make sure those functions fall into "if (!Asm->MF->getFunction()->needsUnwindTableEntry())" case. I'll work on that now.
  3. '__aeabi_unwind_cpp_pr0' which could not be resolved. When JITing C++ code with exceptions, we need to make sure the right libraries are also loaded. I have no idea how to make that.

In theory, just fixing the problem 1 and 2 above should make the tests pass, but if we add C++/EH tests, we need to make sure the libs are loaded.

rengolin updated this revision to Unknown Object (????).Jan 28 2014, 9:08 AM

Right, MCJIT crisis averted, all tests and the test-suite passing, I think it's good to go.

asl added a comment.Jan 28 2014, 9:14 AM

Otherwise - LGTM. Thanks for finalizing this! :)

lib/Target/ARM/ARMAsmPrinter.cpp
1125–1126

Maybe we'd explicitly check for EABI subtarget here?

rengolin added inline comments.Jan 28 2014, 9:32 AM
lib/Target/ARM/ARMAsmPrinter.cpp
1125–1126

That's a good point.

I couldn't find any flag that would directly translate to EABI compatible on all systems (including gnueabi, android, freebsd), but I think this would do:

bool isEHABICompatible = Subtarget->isTargetAEABI() ||
                         Subtarget->isTargetELF() ||
                         Subtarget->isTargetLinux();
if (isEHABICompatible && !DisableARMEHABI &&
     MI->getFlag(MachineInstr::FrameSetup))
  EmitUnwindingInstruction(MI);
asl added inline comments.Jan 28 2014, 9:53 AM
lib/Target/ARM/ARMAsmPrinter.cpp
1125–1126

Hrm, should we really emit unwinding stuff for ELF targets w/o AEABI? And is it possible that isTargetAEABI() will be false and isLinux() will be true?

rengolin added inline comments.Jan 28 2014, 11:31 AM
lib/Target/ARM/ARMAsmPrinter.cpp
1125–1126

Yes, for gnueabi, that's the norm. AEABI is only enabled with the target is *explicitly* "EABI".

I'm fine with removing the ELF flag, since that was just a guess, but Linux generally means gnueabi, and in fact, if the triple is gnueabi, that won't generate the tables.

I could also add a Subtarget->hasEHABISupport() and do some fiddling with the triples...

rengolin updated this revision to Unknown Object (????).Jan 28 2014, 11:56 AM

Adding isTargetEHABICompatible() to ARMSubtarget, so that we can have a precise definition of an EHABI compliant target. Other targets that also support should change this method accordingly.

Hi Anton,

I needed to get the test-suite bot running a few iterations before the end of the week, so I committed (r200388), we can make the new function more specific later, for now it's good enough. Thanks for the review!

rengolin accepted this revision.Jan 29 2014, 4:03 AM
rengolin closed this revision.