[kaffe] Bug Report: accessing array doesn't throw NullPointerException under MIPS

[Kevin D. Kissell]

Helmer Kraemer writes:

> In order to be able to store large constants that cannot
> be inlined in the instruction stream, kaffe's jitter uses
> a per method constant pool (_not_ to be confused with the
> constant pool of a java class file). This constant pool is
> prepended to the generated native code, so it can be accessed
> with pc-relative addressing.
> 
> Both, the HAVE_fakecall and HAVE_fakecall_constpool macros
> are meant to create a call to some function, but with
> a different return address than the current pc.  
> 
> As such, they get two labels as their argument, the label
> of the function to be called (const_label(2)) and the label
> of the return address (const_label(1)). 
> 
> If it is possible for the architecture (as with i386) to
> inline these labels into the instruction stream, the arch
> should define HAVE_fakecall, causing the labels to be
> inlined into the instruction stream. It is the responsibility
> of HAVE_fakecall to set the location of the labels (l->at).
> 
> If it is not possible for the architecture to inline these
> labels into the instruction stream, it should #define
> HAVE_fakecall_constpool. This causes kaffe to put the
> labels into the beforementioned constpool. Again, it is
> the responsibility of HAVE_fakecall_constpool to set
> the location of the label (l->at) properly. 
> 
> Not sure whether this helps you any further , though 

On the basis of what you just said, it does appear that
the i386 JIT emits the branch target address into the
instruction stream, whereas the MIPS version pulls it
out of the constant pool.  So in fact, an architecture
should have only one of HAVE_fakecall and HAVE_Fakecall_constpool
defined, and regardless of how it's done, the name attached
to the mechanism in the jit3-arch.def file should be fake_call?
If that's true, then MIPS would superficially appear to be 
clean in that regard....

            Many Thanks,

            Kevin K.