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.
_______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
