This is the mail archive of the
mailing list for the GCC project.
Re: gcj, shared libraries, and -Bsymbolic
Richard Henderson writes:
> What you actually want is (at least for -findirect-dispatch) is to
> not export any symbols whatsoever. And to do so as simply as not
> marking the symbols TREE_PUBLIC in the front end.
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.
> Without -findirect-dispatch, mixing with C++ code causes problems,
> marking .hidden doesn't work for java libraries referencing other
> libraries. Marking .protected would work, but implies enough extra
> overhead so as to not make it worthwhile (since we have no way to
> indicate to the dynamic linker that we do not need function pointer
> equality semantics).
I intend to submit a patch to mark Java symbols .protected. Most Java
libraries (i.e. those that contain no CNI code) can be built with
-Bsymbolic, so I would assume the overhead of .protected will go away.
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.
> I was actually looking at -findirect-dispatch the other day, but
> got distracted...
It happens. :-) We know that the current scheme is rather inefficient
in that it uses slow linear searches, etc, but it has mostly the