Binary compatibility for virtual fields

Sat Sep 20 13:46:00 GMT 2003

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.