[kaffe] patch for kaffe1.0.7jit3 code runing on MIPS

[Casey Marshall]

>>>>> "Timothy" == Timothy Stack <stack at cs.utah.edu> writes:

>>  There is libunwind
>> <http://www.hpl.hp.com/research/linux/libunwind/>, but it only
>> supports x86 and IA-64.
>> 
>> GCC has fairly sophisticated unwinding support, in gcc/unwind*. For
>> MIPS, and probably most other architectures too, it uses the
>> DWARF-2 debugging format for unwinding, because that format stores
>> information such as what registers get saved on the stack, and
>> where. It can also do file names and line numbers (something I'm
>> investigating right now, because I would like to get debugging
>> stack traces in GCJ without having to fork external processes).

Timothy> So, are you trying to get GCJ to work on MIPS as well?

Yes. I've been able to get the interpreter running in pretty short
order, even. Most of the hacking I had to do was in libffi, which
might even be useful in Kaffe. I sent patches to
java-patches at gcc.gnu.org if anyone is interested.

Right now I have almost no problems running on a patched version of
GCJ 3.3.3, and the libjava test suite gets about 12 FAILs, half of
which are because I stripped out half the class library. And I may
investigate patching 3.4.0 instead, since it has a lot of improvements
on MIPS.

>> The problem with that approach in Kaffe would be that you would
>> need to generate that debugging info for jitted frames, and I don't
>> know how well that would fit into the unwinder (it looks, to me,
>> very specific to ELF).

Timothy> I ran into similar problems with the powerpc jitter.
Timothy> Eventually, I came to the conclusion that the best thing to
Timothy> do for the immediate future is to just forget about trying to
Timothy> unwind any code not produced by the jitter and dump the
Timothy> registers before calling any native code.  It'd be a
Timothy> performance hit, but generating the right DWARF junk and
Timothy> whatever else was just getting too complicated.  Anyways, you
Timothy> still need to deal with code that doesn't have unwind info...

Timothy> You might want to look at what mono or one of the other VMs
Timothy> do here...

You could, at least, guarantee that the native VM code has this info
(-fexceptions). I think trying to unwind through random broken JNI
code is outside the scope of a VM.

This is an interesting problem! Definitely worthy of a hacker's time,
and the mipsel JIT3 is so close to working it isn't even funny.

-- 
Casey Marshall || csm at gnu.org