[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