[kaffe] MIPS JIT3 and null pointers.

[Kevin D. Kissell]

Casey Marshall wrote:
> Ok, more info:
> 
>   1) __mipsGetNextFrame tries to determine the previous frame's
>      program counter and frame pointer, based on the current pc and
>      fp and walking up the code.

[Begin hooting of alarm klaxon]

>   2) When it tries to do this when walking back from a `soft' C
>      method, it gets wrong values. In this case, it gets an address in
>      `mips_do_fixup_trampoline' for the previous pc (which I think
>      should be a jitted method instead), and a pointer to an instance
>      of NullPointerException for the previous fp (this should be an
>      address on the stack).
> 
>   3) The value for the previous frame pointer is invalid since it's
>      way lower than the current frame pointer, so __mipsGetNextFrame
>      fills in pc and fp with zero to mark what it thinks is the end of
>      this stack.

The register used as a "frame pointer" in the MIPS calling sequence/ABI,
GPR 30, isn't generally used as a frame pointer in MIPS Linux.  It's treated
as a ninth "static" register ("s8" in the assembler idiom).  Frame pointers
aren't strictly speaking necessary if one's compiler and debugger know
how to keep track of stack frames on-the-fly, which has been the case
with gcc/gdb for a long time now.  If the Kaffe JIT needs to use one,
I could understand that, but it should not assume that it's been passed
a valid one if invoked from C.  If it wants to create and use one itself,
it can use r30, provided that it respects the static character of the
register, and saves/restores the value provided at entry to a subroutine.

		Regards,

		Kevin K.