EH and call conversion integration

Project Infrastructure LLVM Dev List Archives
#1

Hello!

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:

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

Further, there is also a problem with calling conversions with C++. C++ compilers can emit different return type conversions for struct or class types (as well as I am aware GCC uses pass-by-pointer, which is usually not used for structs with only 2 integers etc) and also different push strategies (this especially applies for member funcion call, where this pointer is passed through ECX register or as first argument).

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?
The problem in the engine is that the basecode will be generated statically for each platform while all scripts (that should be compiled) will be JIT-ed. I would still need to make special care so that scripts will actually compile to the same thing (since they are not C++) but will the llvm be compatible on all targets for JIT and anything else?

I am also asking how stables are llvm and llvm-gcc under cygwin (since our engine is windows based)? Do you think that we can compile such thing without really big problems (and hacks)?

Regards,
®iga

#2

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.

* 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 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 :slight_smile:

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.

-Chris

#3

Chris Lattner pravi:

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 :slight_smile:

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

#4

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