[LLVMdev] EH and call conversion integration
sabre at nondot.org
Mon Nov 20 13:16:40 CST 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 ...
>>> * 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.
More information about the LLVMdev