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

[Helmer Krämer]

On Wed, 12 Mar 2003 15:08:29 +0100
"Kevin D. Kissell" <kevink at mips.com> wrote:

> 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.

Yes.

> So in fact, an architecture
> should have only one of HAVE_fakecall and HAVE_Fakecall_constpool
> defined

Yes.

> and regardless of how it's done, the name attached
> to the mechanism in the jit3-arch.def file should be fake_call?

The jitter accesses the methods of the backend that
emit native code only through the HAVE_* macros in
jit3-icode.h. On the one hand, these macros are used
to determine what instructions are provided by a
specific backend (if an instruction i is provided, the
corresponding HAVE_i macro has to be defined). On the
other hand, these macros expand to the name of the
function that emits native code for that instruction.

These functions that emit native code are defined
in the jit3-arch.def file with the define_insn
macro. The second argument of that macro gives the
name of the function, while the first argument of
that macro is unused. So, to finally answer your
quesition ;), you don't have to use "fake_call"
as the first argument of define_insn, just choose
a value that somehow describes the instruction that
is handled by the function being defined.

Greetings,
Helmer