Question about EH

Per Bothner per@bothner.com
Fri Feb 25 12:18:00 GMT 2000


I wrote something last year about how to solve this problem.
I don't remember where - it might well have been a Cygnus-internal
mailing list.

I also don't remember what I wrote, but I vaguely remember I concluded
that the exception table for a C++ compilation unit should contain
pointer to valid C++ type descriptors.  I.e. if C++ code has an
exception handler for a (pointer to a) Java class, the exception range
table should point to a valid C++ type descriptor.

Tom Tromey <tromey@cygnus.com> writes:

> It does not.  In fact, you have to compile native methods (written in
> C++) with -fno-rtti.
> 
> I don't know why this decision was made.  I definitely don't know all
> the issues.

I don't recall that a decision was made.  It may be a side effect of
vtables: Because the Java compiler generates vtables for Java classes,
it would be pointless to have the C++ compiler also generate vtables
for Java classes.  I'm guessing when and how C++ typinfo objects are
generated is tied to when and how vtables are generated.  (This makes
sense since vtables point to typeinof objects.)

We have the option of hacking the C++ compiler so it emit
typeinfo objects for Java classes, even though it doesn't emit vtables.
However, I don't think that is the right solution.  For one thing, we run
into the usual problem that we don't know *which* compilation unit
should generate the typeinfo object.  The logical choice is that the
typeinfo object should be emited by the copilation unit that contains
the vtable - that is the .o file generated by the Java compiler.

But having jc1 generate valid C++ typeinfo objects is only part of
the problem.  We also need to be able to easily map from the C++
typeinfo object to a Java Class object.  We could do this using the
type names, but that is problematical, since there can be multiple
Java classes with the same name, as long as they are loaded/managed
by different ClassLoaders.  The logical solution is to make sure
there is a pointer from the C++ type descriptors to the Java Class
object.  An even better solution to *embed* the C++ typeinfo in the
Java class, perhapos using multiple inhgeritance:

class java::lang::Class : public java::lang::Object, public std::type_info
{
   ...
}

or:

class java::lang::Class : public java::lang::Object
{
   ...
  std::type_info typeinfo;
}

We can then also change the exception tables for code generated by the
Java compiler to also point to a C++-style type_into object.
This improves Java/C++ compatibility even more, by making them
compatible, even at the typeinfo layer, especially if you also change
the Java vtables so the first element points to the typeinfo sub-object,
rather than the Class object.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/


More information about the Gcc mailing list