banging my head against the wall.... _GLOBAL__I__*?
Mon Jan 28 11:14:00 GMT 2002
Per Bothner <email@example.com> writes:
> I think there is a lot of room for a more compact encoding
> of reflective data. You may have seen the relatively recent
> discussion on this topic.
Yes, certainly. Do you see any opportunities for compacting that
wouldn't get picked up (imperfectly) by compression? I'm mainly
concerned about the compressed size of my binaries, so optimizations
that decrease the uncompressed size but not the compressed size (for
example huffman-coding Utf8Const's) isn't a very high priority for me.
> > 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).
> Don't get hung up on the actual XXX - it is just a magic mangling to
> create a unique symbol.
Aha! Thanks. That was really confusing me.
> > 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?).
> Not necessarily. Why don't you look at the assembly code?
I did... it calls _Jv_RegisterClass(NULL), but I need to know what the
argument is "supposed" to be (instead of NULL).
Actually, I guess I could try it on an unstripped binary to see what
the "correct" argument is...
More information about the Java