sjlj-exceptions handlying

in llvm-backend did't support sjlj-exceptions handlying,but support
dwarf-excceptions handlying,
my question is: if i want change llvm-backend to support, how should i Do ?
anyone can give some clue?

bestregards
zhangzw

It's hard to say - I'm not sure anyone here knows how gcc handles sj/lj
style exceptions, or has a good idea of what would be involved to get LLVM
support. There's some documentation in gcc, see gcc/ada/raise-gcc.c, line 227
and onwards.

Ciao,

Duncan.

Or, reworded slightly, some people here wrote it. :slight_smile:

> I'm not sure anyone here knows how gcc handles sj/lj style exceptions,

Or, reworded slightly, some people here wrote it. :slight_smile:

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?

Thanks,

Duncan.

Don't see why not, though, these aren't sufficient.

What about the -lowerinvoke pass? Is it incomplete?

Best regards,
--Edwin

What else is needed? Want to give a quick rundown on sj/lj eh
and how it differs from dwarf?

Ciao,

Duncan.

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.