[LLVMdev] EH and call conversion integration

[Žiga Osolin]

Chris Lattner pravi:
> On Sat, 18 Nov 2006, [ISO-8859-2] Žiga Osolin wrote:
>> I am currently trying to make EH (exception handling) possible to be
>> integrated in C++. This means that C++ code can throw exceptions and
>> llvm code can catch such exception and llvm can throw exceptions that
>> C++ can catch (or pass through). There are quite some difficulties with
>> approach:
>
> Cool!  This is the major missing feature for full C++ support, it 
> would be welcomed.
>
>>
>> * I must write ABI specific backends for EH. Since we support Visual
>> Studio and GCC, two different backends should be written. I am not sure,
>> however, that EH is the same on all platforms ... so drivers for EH
>> should probably be platform and ABI specific ...
>
> Right.  There are different components: the front-end and middle-end 
> which lower and represent EH info, and the backend which translates it 
> into a form for the specific target.  VC++ and GCC uses totally 
> different ABIs, so the X86 backend will have to support both.
So the best way to support EH is to write a patch for X86 (and later on 
other targets) that would translate the llvm throw, catch and other 
instructions into correct ABI specific code? This code could then throw 
and other code could catch ...
>
>> * I do not know how to write code in such way, that C++ compiler nad
>> llvm will be able to have the same type information for the same types
>> (or to enable casts, e.g. if you throw type X extends Y and Y is known
>> to C++, how will this be handled).
>
> There is some front-end work there as well.  I don't know if GCC 
> supports the VC exception handling ABI, if so, that part is done.
I have a small problem, that is that I will generate JIT code and I do 
not know how to access typeinfo generated by the C++ compiler. I mean 
all the exceptions should probably have RTTI (runtime type information) 
enabled by default (this is standard), but I must be able to match type 
IDs so the C++ and JIT code can comunicate.

Many other project would probably also require C++ JIT code to actually 
interact with compiled C++ code (at least with GCC which is portable). 
However, the compatibility on Visual studio is another question because 
the method singatures are different. And to make this actually work, I 
will probably use mingw on windows too (and compile my application 
either with llvm-gcc or gcc, will see how it will work).
>
>> I think with all these problems (and more are likely to arise), I don't
>> know if it still makes sense to apply such fixes, they are too
>> target/ABI specific. This leaves me with option to try the build tho
>> whole engine (which is 300+k lines) with llvm-gcc. If I understand
>> right, all such problems should disappear. So, if I compile, for example
>> for x86 statically or with JIT, will the code be compatible (always!) at
>> the end?
>
> Yes, but we have no C++ EH implemented yet :)
>
> If you want to start implementing C++ EH in LLVM, for either VC or GCC 
> ABI's, the first step would to make it so that you can throw across an 
> LLVM-compiled frame.  This requires emitting EH info for the function.
So what is the status of EH on llvm. I know you emit correct code and do 
all kinds of optimisations. So the backends just ignore that code, or 
what? Because I have seen from your approach that "all" you have to do 
is specify the replacements for throw, catch_by_type and other llvm 
internal handler functions.

I have also seen on your personal page that you have some complaints 
about current EH system, will this effect this work (for example, will 
it have to be rewritten when the EH system is rewritten)?
>
> -Chris
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>