[LLVMdev] EH and call conversion integration

Chris Lattner sabre at nondot.org
Mon Nov 20 11:16:40 PST 2006


On Sun, 19 Nov 2006, [ISO-8859-2] Žiga Osolin wrote:
>> 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 ...

Yes.

>>> * 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.

That means you will need ABI-specific code in your JIT.

>> 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.

llvm-gcc4 does not support EH at all.

> 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)?

If and when someone tackles these projects, they will be sure to upgrade 
whatever code already exists.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/


More information about the llvm-dev mailing list