[BC ABI] gcj-abi-2-dev-branch created

Tom Tromey tromey@redhat.com
Tue Apr 20 05:40:00 GMT 2004

>>>>> "Bryce" == Bryce McKinlay <mckinlay@redhat.com> writes:

Bryce> OK, you might be right. With the BC-ABI, the mangling isn't really all
Bryce> that important since the symbols will be private, the compiler could
Bryce> call them whatever it likes since the runtime can do all the
Bryce> linking. As for the standard ABI, instead of actually changing the
Bryce> mangling format I think it should be sufficient to add something like
Bryce> "$$return_type" to a method name in the cases where conflicts
Bryce> occur. This should allow us to keep generating .h files for CNI
Bryce> without having to dramatically alter either CNI or the C++ compiler.

I have a few questions about how CNI is going to continue to function.

One question is how CNI code will contribute to the otable.  That
seems like a major problem.

For mangling, Andrew had the idea that we would emit static
initializers to register CNI methods with the runtime, basically akin
to JNI function registration.  So perhaps that problem is

The point you bring up is an important one.  If CNI can contribute to
the otable, then we just need to teach g++ about our own weird
mangling (or add an attribute or something).  That might work.

Another idea would be to declare that CNI can't work with BC code.  In
this case the above approach might not work, or at the very least we
would need to make gcjh much smarter so that overriding is computed
correctly by g++.

Bryce> As an aside, I'm not really sure that we need to keep the "covariant
Bryce> bridge methods" at all when generating .o output. I haven't discovered
Bryce> a situation yet where the bridge methods generated by the compiler do
Bryce> anything more than call the real method?

We talked about this on irc, but I thought I'd put the answer out to a
wider audience.  The bridge methods are needed for runtime type
safety, and if you omit them, then at runtime you can perform invalid
unchecked casts.

The example:

    class base<T> {
      public T obj;
      public void set (T x) { obj = x; }

    case der extends base<String> {
      public void set (String x) { x.something(); }

    der foo;
    base oops = foo;  // this gets a compiler warning but is correct
    oops.set (new Object ()); // remember we omitted the bridge, so 
                              // no cast to String is performed

Ordinarily the compiler would generate a `der.set' that looks like:

  public void set (Object x) { this.set((String) x); }


More information about the Java mailing list