Re: org.xml.* not in libgcj but libgij

[Michael Matz <matz at suse dot de>]

Hi Tom,

On Mon, 18 Apr 2005, Tom Tromey wrote:

> Yeah.  This got fixed recently:
> 
> 2005-04-15  Tom Tromey  <tromey@redhat.com>
> 
> 	* Makefile.in: Rebuilt.
> 	* Makefile.am (libgij_la_LIBADD): Moved SAX and DOM...
> 	(libgcj0_convenience_la_LIBADD): ... here.

Bummer.  6 hours after the checkout I used ;-)

> Michael> With that patch we get a little further, in that trang links.
> Michael> But it doesn't work, for the same reasons for that also this
> Michael> testcase breaks to run:
> 
> This won't work because it is a C++ ABI class that directly depends on
> a BC ABI class.  We have to compile the various XML classes, and their
> dependents with the binary compatibility ABI to enable replacing them

Let me make sure I understand this (you see, I'm no Java guru ;) ): The 
org.xml.* classes can be replaced at runtime (by using endorsed dirs).  
Therefore they can't be compiled like normal binary code, as the linker 
would resolve the symbols at link time (or the dynlinker at starting) in 
the various vtables, and the later dynamic loading wouldn't work, as it 
wouldn't change the contents of the vtables.

So, instead of directly resolving you go over a wrapper function, which 
instead implements the java lookup rules.  And this has only to be done 
for classes which can be replaced, i.e. nothing of the core API (like 
java.lang.*) for instance.  That's why you don't use -findirect-dispatch 
by default.

Wouldn't it make sense (and is it possible at all) to be able to say 
optionally "I'm sure I never dynamically load a class, please hardcode 
everything"?  I think that would be an option for the class loader, i.e. 
at runtime, where it would have to initialize the org.xml.* classes like 
all the others.  Is that possible?  (I'm not 100% sure if that's sensible, 
but perhaps in a distribution setting it might).

> at runtime.  This functionality is needed by some applications, the
> one of note being Jonas.
> 
> It would be great if we could give an error if you try to do this,
> since for one thing that would save a lot of headache when maintaining
> the libgcj build itself.  In the future, when/if we make BC symbols
> private, I suppose you'll get a link error.

Yep.  Making them private is one possibility.  With binutils one could 
also mark them funnily, like strlen for instance.  When a section
  .gnu.warning.A_SYMBOL
is present, and A_SYMBOL is used from the shared library, then the user 
will get a warning which consists of the contents of that warning.  I 
guess annotating the ctors of all classes compiled with 
-findirect-dispatch would be enough for the user.  For instance compiling 
this file with gcc, and linking it together with A.java (when compiled 
without -findirect-dispatch) on a glibc/binutils/ELF platform makes it 
print a warning message from ld:

---------------------------------
#define __make_section_unallocated(section_string)   \
  asm (".section " section_string "\n\t.previous");
#define __sec_comment "\n\t#"
#define link_warning(symbol, msg) \
  __make_section_unallocated (".gnu.warning." #symbol) \
  static const char __evoke_link_warning_##symbol[]     \
    __attribute__ ((used, section (".gnu.warning." #symbol 
__sec_comment))) \
    = msg;
link_warning(_ZN3org3xml3sax7helpers14DefaultHandlerC1Ev,
  "When using org.xml.* classes, you have to compile with -findirect-dispatch")
---------------------------------

% gcj --main=A A.java warn-syms.o
/tmp/ccwBPFky.o: In function `A::A()':
A.java:(.text+0x6a): warning: When using org.xml.* classes, you have to 
compile with -findirect-dispatch

With -findirect-dispatch it works.

> If you compile A.java BC, it works fine:
> 
> opsy. gcj -C A.java
> opsy. gcj -findirect-dispatch --main=A -o Q A.class

Btw. I saw it mentioned in the docs, that -findirect-dispatch only works 
with .class files, but not when directly compiling .java files.  The short 
testcases OTOH does work just fine when using -findirect-dispatch on the 
.java source directly.  So, is that documentation outdated, or does it 
just happen to work in this case by luck (and which circumstance would 
make it fail, I'm just curious).


Ciao,
Michael.