Re: Binary compatibility for virtual fields

[Andrew Haley <aph at redhat dot com>]

Bryce McKinlay writes:
 > On Saturday, Sep 20, 2003, at 04:58 Pacific/Auckland, Andrew Haley 
 > wrote:
 > 
 > > This is a heads up:
 > >
 > > I've got binary compatibility for virtual fields working
 > 
 > Great! Have you run any benchmarks?

No, not yet.  Correctness first, y'know?  ;-)
I'm just doing the obvious thing using the same mechanism as
-findirect-dispatch for offsets of fields.

 > > If we're going to remove exported symbols from Java libraries, we'll
 > > have to handle static fields and methods as well.  I don't imagine
 > > that will be very difficult, and I'll get to it ASAP.
 > 
 > Yeah. After that we'll also need generate class objects at runtime.
 > 
 > > Bryce, you said that libgcj couldn't be built with
 > > -findirect-dispatch.  Do you recall what the reason was?
 > 
 > As I recall, somewhere in the runtime the vtables for java.lang.Object 
 > and/or java.lang.Class are referenced directly. So you'd get a link 
 > error for those vtable symbols which won't exist. This problem might 
 > have been fixed since I last checked, however.

'Mkay.

 > > My BC tests are incomplete in that I'm not seeing a failure for
 > >
 > > 	  // FIXME: This does not yet fully conform to binary compatibility
 > > 	  // rules. It will break if a declaration is moved into a
 > > 	  // superinterface.
 > >
 > > I'll add a test for that to Mauve.
 > 
 > BTW: there is a full description of what is lacking for interface calls 
 > in this old post, look for "2. Interface calls":
 > 
 > http://gcc.gnu.org/ml/java/2001-12/msg00209.html

Righto, ta.

Andrew.