Re: libgcj maintenance for 4.0.x branch

[Bryce McKinlay <mckinlay at redhat dot com>]

David Daney wrote:

> Andrew Haley wrote:
>
> > Bryce McKinlay writes:
> >  > Andrew Haley wrote:
> >  >  > >Tom Tromey writes:
> >  > > >
> >  > > > The proposed rule here is actually fairly conservative, 
> > perhaps overly
> >  > > > so.
> >  > >
> >  > >I think so.  I wonder if the idea of never breaking the ABI is a bit
> >  > >too optimistic.  We will try, but ...
> >  > >
> >  > > > Starting with 4.1 I would like to see a much less conservative
> >  > > > rule, namely that we only promise compatibility if you use
> >  > > > -findirect-dispatch.
> >  > >
> >  > >Yes.
> >  >  > I agree, but I also we need to make -findirect-dispatch the 
> > default for  > 4.1. Obviously some things need to happen before we 
> > can do this.
> >
> > Source compilation, in particular.  The fact that it doesn't work is
> > certainly my fault, but I'm pretty sure I know how to fix it.
>
> What is the strategy going to be for CNI?
>
> We have a lot of CNI code that is not part of libgcj, It would be nice 
> to have an easy migration to the BC-ABI.


Yes, changes also need to be made to the C++ compiler so that it can 
speak the BC-ABI. This will involve having the C++ compiler emit BC-ABI 
dispatch code along with the appropriate otable/atable symbols, and 
implementing a way for CNI code to get registered at runtime so that 
libgcj can link the dispatch tables at the appropriate time. Ideally, 
I'd like to see some of the ABI code genericized and moved to the 
generic part of the compiler so it can be shared between the Java and 
C++ front ends, but its not yet clear how difficult that would be.

Bryce