banging my head against the wall.... _GLOBAL__I__*?
Adam Megacz
gcj@lists.megacz.com
Mon Jan 28 10:32:00 GMT 2002
So I've got method-gc compiling HelloWorld into a 133kb gzipped
binary... which is cool because it now makes gcj a very useful
platform for embedded work -- with no VM/JIT logic required and access
to the wide array of gcc backends, it would seem like an excellent way
to write Java code for devices. This should drop below 100kb with gc
disabled, and even lower if I can figure out a way to be more
selective about what reflection data I retain.
Later on (spring?) I'm going to hack up some grungy fallback support
for signals/threads/no-gc/sjlj/natXXX in the hopes of getting a
working gcj on most platforms that gcc supports (albeit with wretched
performance).
Anyways, the last problem I'm struggling with is that my stripped
binaries SEGV somewhere inside the symbol
"_GLOBAL__I__ZN4java4util12AbstractList3addEiPNS_4lang6ObjectE". This
function is called by __main(), and itself does little more than call
_Jv_RegisterClass four times (SEGV is in the third call).
The SEGV is clearly a result of me stripping something out of the
binary that I shouldn't have... but I have no idea where to start
looking since I'm not sure what this symbol does, or which classes it
is trying to _Jv_Register (wild guess: superclasses/superinterfaces of
AbstractList?).
AbstractList.add(ILjava/lang/Object;)V is a pretty trivial method -- I
can't see why it is deserving of a magic __GLOBAL__ symbol, yet
something like String.substring(II) isn't... I also can't figure out
where the C++/Java code for this symbol is -- I'm assuming it's
magically generated by the compiler.
What I really can't figure out is why any part of AbstractList.java
needs to be invoked when the binary is loaded. What if you never
instantiate an AbstractList or any of its subclasses?
One more interesting thing -- when compiling AbstractList.java without
-O2, the symbol name changes to
"_GLOBAL__I__ZN4java4util12AbstractList6finit$Ev", but the behavior is
the same.
Argh.
- a
More information about the Java
mailing list