On Sat, 2004-10-09 at 12:54, Mikolaj Habryn wrote: > And, and... how exactly did that method get JITted in 0 ms? Something > very, very fishy here.
Well, it's a null method, that's how. I'm about puzzled out for one day. Turning on various bits of debug and sprinkling in some dprintfs yields this output just before crashing: Method Constant Pool: 10093da8: (ref) 0x1006baf4 0x1006baf4 10093db0: (ref) 0x2ab51f28 0x2ab51f28 10093db8: (ref) 0x2ab51e40 0x2ab51e40 10093dc0: (ref) 0x1005e2b8 0x1005e2b8 set jitted for method 0x1006baf4 to 0x10093dc8 Translating java/lang/String$ICComp.<init>()V (normal) 0x10093dc8 <JIT: java/lang/String$ICComp.<init>()V time 44ms (220ms) @ 0x10093dc8 (0x1006baf4)> soft_fixup_trampoline(): return 0x10093dc8 soft_fixup_trampoline(): meth 0x1005e2a4, where 0x1005e2b8, native code 0x1005e2b8 callinfo = 0x7fff7590 null call?? 0x1005e2a4 going to soft_null_call 0x2ab50a50 called soft_null_call (0x2ab50a50), seemed to work set native for method 0x1005e2a4 to 0x2ab50a50 Translating java/lang/Object.<init>()V (normal) 0x2ab50a50 <JIT: java/lang/Object.<init>()V time 15ms (235ms) @ 0x2ab50a50 (0x1005e2a4)> soft_fixup_trampoline(): return 0x2ab50a50 Illegal instruction (core dumped) [EMAIL PROTECTED]:~# The crash is an illegal instruction at 0x1005e2b0. Disassembling the region shows: 0x1005e2a4: beq zero,v0,0x1006a708 0x1005e2a8: b 0x1007afac 0x1005e2ac: 0xc801 0x1005e2b0: sdc3 $31,-1(ra) 0x1005e2b4: sll zero,at,0x0 0x1005e2b8: slti s5,s5,2640 Which makes me suspect that it's actually dying at 0x1005e2ac but advancing the PC nonetheless. Or something. Anyway. From the first snippet, you can see that there's something from some previous method's constant pool right after that point, at 0x1005e2b8, and the previous method block itself (?) just before it, at 0x1005e2a4. So, how did we wind up jumping to that address? Broken trampoline? m. _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
