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

[Helmer Krämer]

On Wed, 12 Mar 2003 11:57:06 +0100
"Kevin D. Kissell" <kevink at mips.com> wrote:

> As long as I have your attention, there's one other 
> oddity I've found in the MIPS JIT3 support that you
> might be able to explain.  In jit3-icode.h for MIPS,
> we have
> 
> #define HAVE_fakecall_constpool         fakecall_xCC
> 
> but in jit3-mips.def we have
> 
> define_insn(fake_call, fakecall_xCC)
> {
>         label* tol = const_label(2);
>         label* froml = const_label(1);
> 
>         froml->type |= Lfuncrelative|Llong16;
>         froml->at = CODEPC;
>         ldst_RRC(_LW, REG_ra, REG_gp, 0);
>         debug(("        lw ra,?(gp)\n"));
> 
>         tol->type |= Lfuncrelative|Llong16;
>         tol->at = CODEPC;
>         ldst_RRC(_LW, REG_i25, REG_gp, 0);
>         debug(("        lw t9,?(gp)\n"));
> 
>         insn_RRR(_JALR, REG_i0, REG_i25, REG_i0);
>         debug(("        jr t9\n"));
> 
>         NOP();
> }
> 
> Which follows the model of the i386 definition pretty
> closely, and the i386 jit3-icode.h defines HAVE_fakecall,
> not HAVE_fakecall_constpool.
> 
> So...Is the situation in MIPS-land normal, should the
> jit3-icode.h definition be for HAVE_fakecall instead
> of HAVE_fakecall_constpool, or should the definition
> in jit3-mips.def be of fake_call_constpool instead of
> fake_call?  On a hunch, I tried the modification to
> jit3-icode.h, but the result was neither better nor worse
> on any of the regression tests I'm studying.

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 :(

And as always - I might be totally lost and completely
wrong ;)

Greetings,
Helmer