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