crash loading gcj stuff

[Godmar Back]

> 
> 
> >>>>> "GB" == Godmar Back <gback at cs.utah.edu> writes:
> 
> GB> It's 17.  So change 19 -> 17 in i386/jit.h and try that. 
> 
> Yep, my otherwise unmodified Kaffe is loading gcj-compiled code now.  Neat.

That's great!
I'll see that I get the CVS tree updated to match the most recent version
of gcj.

>
> GB> Here's another hint: if you use optimization as in -O2 or -O3,
> GB> make sure you also use -fkeep-inline to avoid that gcj removes the
> GB> meta-information for private methods it inlines. 
>
> There's one little hitch: when linking kaffeh, if you have
> -fkeep-inline-functions, there will end-up being undefined references
> to postOutOfMemory and throwError via in utf8const.o from checkPtr (a
> static inline in errors.h).
>

No no no.  I meant to compile your .class with -fkeep-inline-functions,
not kaffe or kaffeh.

gcj attempts to inline certain methods.  When it does that without keeping
an outlined copy around, it will not generate entries in the method table.
This will screw up the consistency between kaffe's method/dtable table 
and gcj's vtable.  By giving the keep-inline-flag, we force gcj to keep
entries in the method table even for functions it completely inlines.
In addition to the entry in the method table, it will also keep an 
outlined copy around which can be used for reflective invocation.
In general, when reading in a gcj class and creating the surrogate 
structures, I'm relying on the accuracy of the metadata gcj sticks 
in the object file.

	- Godmar