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

[Casey Marshall]

>>>>> "Dalibor" == Dalibor Topic <robilad at kaffe.org> writes:

Dalibor> Casey Marshall wrote:
>>>>>>> "Dalibor" == Dalibor Topic <robilad at kaffe.org> writes:
Dalibor> Yoshiharu Oba wrote:
>>
>>>> Hi Dalibor I appreciate your advice very much. Now I'm writing a
>>>> changelog and remake a new patch, It's also included.
Dalibor> Thanks a lot! I'll go through it, and see what needs to be
Dalibor> applied to the CVS head. It's great that you got JIT & JIT3
Dalibor> to work. I'd like to get your changes in, and then look at
Dalibor> Casey's patches for JIT & JIT3 from this spring.
>> One thing I was not able to fix in JIT3 was the stack unwinder,
>> which is a particularly bad piece of code. The real problem was
>> that GCC would reorder instructions in the prologue, so the
>> unwinder was not able to find where the function stored $ra. I
>> haven't tried a more recent GCC (I was using 3.1), but I think
>> using `-fno-reorder-insns2' fixes this particular problem.  Also, I
>> really don't much like that unwinder in general. It makes too many
>> assumptions about the way the stack looks, which may not be true in
>> general. GCC's unwinder makes a bit more sense, since it uses
>> debugging info it will typically be consistent.

Dalibor> Is there some general stack unwinder library/API we could use
Dalibor> for that? I've seen that mprotect has some code for such
Dalibor> things for mips, sparc, i386, etc. How does gcc/gcj deal with
Dalibor> that problem?

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

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

-- 
Casey Marshall || csm at gnu.org