ARM and lowerinvoke

All,

I'm looking at the lowerinvoke pass as a starting point for getting SJLJ based exception handling working on ARM, but am having some troubles with it. When I run a simple testcase (attached) through llc and specify -enable-correct-eh-support, llc asserts on me. It appears there's been some bitrot somewhere. SelectDAGBuild and SelectionDAGISel cooperate to track landing pads with CatchInfoLost and CatchInfoFound and make sure they're all handled. However, lowerinvoke throws a wrench into that by getting rid of the explicit invokes, so SelectionDAGISel never identifies any landing pads, and then complains with:
Assertion failed: (FuncInfo->CatchInfoFound.size() == FuncInfo- >CatchInfoLost.size() && "Not all catch info was assigned to a landing pad!"), function runOnFunction, file /Volumes/Home/grosbaj/sources/llvm-public/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp, line 350.

Is it reasonable to expect that lowerinvoke is a good place to start for doing what I'm after? Assuming so, I could use a bit of background education on what's going on with this assertion and how to correct it. Where is a good place to look to get that?

Thanks
   Jim

test.bc (1.8 KB)

test.cpp (239 Bytes)

Hello, Jim

-enable-correct-eh-support, llc asserts on me. It appears there's been some
bitrot somewhere.

Well, correct. Because many places expects exceptions to be dwarf-style.

Is it reasonable to expect that lowerinvoke is a good place to start for
doing what I'm after?

I really don't think so. Since you're trying to map dwarf-based
structures into sjlj couch. I think you need to start looking how gcc
/ llvm-gcc implements them, do proper lowering inside llvm-gcc and
then "fix" DAG machinery & backends to emit correct sjlj info.

on what's going on with this assertion and how to correct it. Where is a
good place to look to get that?

It's funny, but: gcc/ada/raise-gcc.c
It describes both exception schemes. After that you might look how
different stuff (dwarf vs sjlj) is lowered in gcc and try to extend
llvm-convert to do something similar.

Hi Jim,

One thing to know about lowerinvoke is that it does not conform at all to a native ABI. If you need to interoperate with existing code, you can't use it.

-Chris

True. My idea was to use it as a starting point, then make something from there that conforms to the ABI I need. That is, it definitely isn't sufficient in and of itself, but I was hoping it would be a decent beginning. Sounds like that may not be the case.

-Jim

Is it reasonable to expect that lowerinvoke is a good place to start for
doing what I'm after?

I really don't think so. Since you're trying to map dwarf-based
structures into sjlj couch. I think you need to start looking how gcc
/ llvm-gcc implements them, do proper lowering inside llvm-gcc and
then "fix" DAG machinery & backends to emit correct sjlj info.

Yeah, I'm (somewhat) familiar with the sjlj stuff in GCC. I was hoping to avoid too many changes to the front end, as that would, theoretically, reduce the amount of work clang will need when it comes rolling around to this stuff. Not going to work out that way, it seems. C'est la vie.

Thanks!

-Jim

Hi Jim,

I'm looking at the lowerinvoke pass as a starting point for getting
SJLJ based exception handling working on ARM, but am having some
troubles with it. When I run a simple testcase (attached) through llc
and specify -enable-correct-eh-support, llc asserts on me. It appears
there's been some bitrot somewhere. SelectDAGBuild and
SelectionDAGISel cooperate to track landing pads with CatchInfoLost
and CatchInfoFound and make sure they're all handled. However,
lowerinvoke throws a wrench into that by getting rid of the explicit
invokes, so SelectionDAGISel never identifies any landing pads, and
then complains with:
Assertion failed: (FuncInfo->CatchInfoFound.size() == FuncInfo-
>CatchInfoLost.size() && "Not all catch info was assigned to a
landing pad!"), function runOnFunction, file /Volumes/Home/grosbaj/
sources/llvm-public/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp,
line 350.

the lowerinvoke pass doesn't know anything about LLVM's exception
handling intrinsics, eh.exception and eh.selector. The code generator
checks that these intrinsics only turn up in landing pads. Since lower
invoke gets rid of landing pads but doesn't touch the intrinsics, you
get this failure.

Is it reasonable to expect that lowerinvoke is a good place to start
for doing what I'm after? Assuming so, I could use a bit of background
education on what's going on with this assertion and how to correct
it. Where is a good place to look to get that?

I think the first thing to do is to understand how sj/lj exceptions
are implemented in gcc. I don't understand this myself. It looks
like a lot of the dwarf and sj/lj code is unified.

Ciao,

Duncan.

Hi Duncan,

Assertion failed: (FuncInfo->CatchInfoFound.size() == FuncInfo-

CatchInfoLost.size() && "Not all catch info was assigned to a

landing pad!"), function runOnFunction, file /Volumes/Home/grosbaj/
sources/llvm-public/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp,
line 350.

the lowerinvoke pass doesn't know anything about LLVM's exception
handling intrinsics, eh.exception and eh.selector. The code generator
checks that these intrinsics only turn up in landing pads. Since lower
invoke gets rid of landing pads but doesn't touch the intrinsics, you
get this failure.

Ah, OK. That makes sense. I think I overestimated the scope of lowerinvoke's intention a bit. I was under the impression that the intrinsics were handled in conjuction with the pass and played nicely with one another. That's obviously expected to be handled separately.

I think the first thing to do is to understand how sj/lj exceptions
are implemented in gcc. I don't understand this myself. It looks
like a lot of the dwarf and sj/lj code is unified.

Yep. Absolutely agree. GCC keeps a lot of the high level stuff together, thankfully. One of the things I'm hoping to get out of this process is a bit of documentation about how sjlj exceptions work, and how that ties in with the implementation. I'm making slow but good progress, overall.

Thanks for taking the time to explain where I'm getting confused. Very helpful.

Regards,
   -Jim