On Feb 17, 2009, at 8:59 AM, Duncan Sands wrote:> Excellent! To handle dwarf eh, LLVM has an intrinsic to get hold of > an exception object (eh.exception) and an intrinsic for matching the > exception against a list of typeinfo objects (eh.selector). These > get morphed into calls to the gcc unwinder lib by the code generator. > Can sj/lj follow a similar scheme?Don't see why not, though, these aren't sufficient.
On 2009-02-17 19:04, Mike Stump wrote:> On Feb 17, 2009, at 8:59 AM, Duncan Sands wrote: > >> Excellent! To handle dwarf eh, LLVM has an intrinsic to get hold of >> an exception object (eh.exception) and an intrinsic for matching the >> exception against a list of typeinfo objects (eh.selector). These >> get morphed into calls to the gcc unwinder lib by the code generator. >> Can sj/lj follow a similar scheme? >> > > Don't see why not, though, these aren't sufficient.What about the -lowerinvoke pass? Is it incomplete? Best regards, --Edwin
On Tuesday 17 February 2009 18:04:43 Mike Stump wrote:> On Feb 17, 2009, at 8:59 AM, Duncan Sands wrote: > > Excellent! To handle dwarf eh, LLVM has an intrinsic to get hold of > > an exception object (eh.exception) and an intrinsic for matching the > > exception against a list of typeinfo objects (eh.selector). These > > get morphed into calls to the gcc unwinder lib by the code generator. > > Can sj/lj follow a similar scheme? > > Don't see why not, though, these aren't sufficient.What else is needed? Want to give a quick rundown on sj/lj eh and how it differs from dwarf? Ciao, Duncan.
On Feb 17, 2009, at 9:52 AM, Duncan Sands wrote:> On Tuesday 17 February 2009 18:04:43 Mike Stump wrote: >> On Feb 17, 2009, at 8:59 AM, Duncan Sands wrote: >>> Excellent! To handle dwarf eh, LLVM has an intrinsic to get hold of >>> an exception object (eh.exception) and an intrinsic for matching the >>> exception against a list of typeinfo objects (eh.selector). These >>> get morphed into calls to the gcc unwinder lib by the code >>> generator. >>> Can sj/lj follow a similar scheme? >> >> Don't see why not, though, these aren't sufficient. > > What else is needed? Want to give a quick rundown on sj/lj eh and > how it differs from dwarf?From a practical perspective, compile up g++.mike/eh6.C and see if it matches gcc codegen on a sjlj platform. From there, run the testsuite with eh\*.C and see if they all work. This should go a long way to pointing out deficiencies, if any. I've not been watching carefully how llvm-gcc is wired into llvm with respect to EH, to know if you guys are reusing gcc to do the codegen, or if these are being passed on down to llvm for codegen. clang of course has a slightly different answer here.