This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: More questions about _GLOBAL [[ how I finally solved it ]]
Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
> > now I just have
> >method-gc strip out all .ctors / .jcr sections and rebuild them
> >manually for all known-to-be-reachable classes by spitting out a
> >simple assembler source file and including it in the link.
> If you're doing that, can't you just strip all the __GLOBAL__I__ symbols
> regardless of what they're called? So no need to change
> emit_register_classes()?
Unfortunately no, since .ctors must contain nothing but pointers to
functions, and it takes two instructions (a MOV and a CALL) to invoke
_Jv_RegisterClass(), since it requires an argument. So there has to be
a second level of indirection.
Furthermore, as emit_register_classes() stands, there are two problems:
1) Sometimes two classes will share a __GLOBAL__I__, and the sharing
rules can't be inferred without parsing the .java source code again.
2) Naming of the __GLOBAL__I__ sections is nondeterministic -- it
seems to be derived from a randomly-chosen symbol.
So I have to use some sort of __GLOBAL__I__-ish construct, and I have
to change emit_register_classes() in order to make the existing ones
suitable.
I guess I could also build my own __GLOBAL__I__-ish code segments, but
I'd rather use the ones that are already there unless somebody has an
objection to my emit_register_classes() patch.
- a