This is an archive of the discontinued LLVM Phabricator instance.

[ARM] Use dwarf exception handling on MinGW
ClosedPublic

Authored by mstorsjo on Nov 2 2017, 1:25 AM.

Details

Summary

Enabling and using dwarf exceptions seems like an easier path to take, than to make the COFF/ARM backend output EHABI directives. Previously, no EH model was enabled at all on this target.

There's no point in setting UseIntegratedAssembler to false since GNU binutils doesn't support Windows on ARM, and since we don't need to support external assembler, we don't need to use register numbers in cfi directives.

Diff Detail

Repository
rL LLVM

Event Timeline

mstorsjo created this revision.Nov 2 2017, 1:25 AM
compnerd edited edge metadata.Nov 2 2017, 1:38 PM

We really do not want to use EHABI on Windows ARM. We should be emitting the Windows exception tables, which would allow zero cost exceptions that can work across the boundary. The information for that model is fully documented and decodable in the LLVM sources (I added all the necessary structures and the decoder for that a while ago). I haven't had a chance to implement the necessary assembler support to enable the generation of the .pdata and .xdata sections.

lib/Target/ARM/MCTargetDesc/ARMMCAsmInfo.cpp
111 ↗(On Diff #121243)

Why was this false? Please tell me I didn't screw that up.

We really do not want to use EHABI on Windows ARM. We should be emitting the Windows exception tables, which would allow zero cost exceptions that can work across the boundary. The information for that model is fully documented and decodable in the LLVM sources (I added all the necessary structures and the decoder for that a while ago). I haven't had a chance to implement the necessary assembler support to enable the generation of the .pdata and .xdata sections.

That's probably the best target in general, yes. That also requires a matching personality function in libcxxabi (as discussed on irc some weeks ago), right? I chose trying to implement this with dwarf initially since it seemed to be very simple to get working, although it's probably not the intended permanent solution. But I can understand if you don't want such a non-final thing committed.

lib/Target/ARM/MCTargetDesc/ARMMCAsmInfo.cpp
111 ↗(On Diff #121243)

I have no idea why it was false, but apparently it hasn't caused any other issues so far. I only noticed when I wanted to change DwarfRegNumForCFI when I tried to add a testcase for this.

So, what's your take on this one - go ahead with this (as you approved D39533 ) until we have WinEH support in libcxxabi and have finished emitting .pdata and .xdata for arm? Or hold off of that (and possibly just fix the UseIntegratedAssembler flag which is a little strange as is)?

I just haven't had a chance to look through the test changes, the code changes seem reasonable. As much as I hate the dwarf unwinding approach, I can understand why you are using that. I don't think that I would be able to add the WinEH support quickly, so, I think that this is a pragmatic compromise.

compnerd accepted this revision.Nov 16 2017, 10:27 PM
This revision is now accepted and ready to land.Nov 16 2017, 10:27 PM
This revision was automatically updated to reflect the committed changes.