This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcj, shared libraries, and -Bsymbolic

Richard Henderson writes:
 > On Wed, Jan 26, 2005 at 09:54:58AM +0000, Andrew Haley wrote:
 > > I know.  However, at present this breaks CNI.  The Right Way to solve
 > > this is to fix CNI so that calls to Java methods use the Java
 > > runtime's name resolution scheme.  However, we have a pressing
 > > deadline for the 4.0 release.
 > How much work do you think it is?

Hard to say because we don't have a complete design yet.  

To call Java from CNI requires some static initialization code to be
generated to call Java's resolver for static method addresses,
classes, and so on.

To call CNI from Java requires some static initialization code to be
generated to register C++ methods with the java runtime.

All this has to be inserted into the C++ compiler somehow.  It's not
hugely difficult, but it requires thought and fairly thorough testing.
Also, we don't want to introduces much more overhead than already
implied by the PLT and the GOT.

 > > Can you give me some idea just how much extra overhead is implied by
 > > .protected?  It seems to me that it has the semantics we require.
 > Pretty significant.  If you ever take the address of a protected
 > symbol (which I think you're likely to do, building vtables), then
 > we have to search all the modules in the symbol search path for 
 > the first one that defines a plt entry for that symbol.  That plt
 > entry becomes the canonical value for that symbol.
 > We really REALLY need some pointer-type relocations that explicitly
 > say that function pointer equality is not required, cause that's the
 > only way to fix this.

That's what I was thinking.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]