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 -------------- next part -------------- A non-text attachment was scrubbed... Name: test.bc Type: application/octet-stream Size: 1840 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090421/e00e4b1f/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: test.cpp Type: application/octet-stream Size: 239 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090421/e00e4b1f/attachment-0001.obj>
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. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
On Apr 21, 2009, at 1:53 PM, Jim Grosbach wrote:> 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.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
On Apr 21, 2009, at 2:52 PM, Chris Lattner wrote:> On Apr 21, 2009, at 1:53 PM, Jim Grosbach wrote: >> 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. > > 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. >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
On Apr 21, 2009, at 2:37 PM, Anton Korobeynikov wrote:>> >> 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> -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State > University > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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, On Apr 22, 2009, at 12:08 AM, Duncan Sands wrote:>> 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
Apparently Analagous Threads
- [LLVMdev] ARM and lowerinvoke
- [LLVMdev] ARM and lowerinvoke
- [LLVMdev] Assertion Failure: Not all catch info was assigned to a landing pad
- [LLVMdev] ExtractBasicBlock() on block that ends with invoke or unreachable triggers assert() in llc
- [LLVMdev] ARM and lowerinvoke