Re: [kaffe] Re: flestmail - daily - 365/365 passed (100.0%) (0 errors, 0 failures)
On Tuesday, September 17, 2002, at 10:52 PM, Patrick Tullmann wrote: [infinite exception dispatch loops] So, lets try and reexamine the whole thing... First, what does the pc in the parameter list correspond to? The current pc or the next pc? Anyway, I would expect the pc passed to findExceptionBlockInMethod to be the current pc (i.e, the point where the exception occured). I think code that passes in something else is probably broken, right? agreed Oops... Maybe we should change the intrp engine to set mjbuf-pc to npc and see if that fixes it. Wouldn't that break the code that jumps to an exception handler and re-sets the PC based on the exception handler? From the looks of it, this is two distinct uses of the same field. The intrp engine uses it to tell the exception code where it is in the method and what handler should apply, but, otherwise the value placed in there is ignored. Then, the exception code uses it to tell the engine what code to execute next, in this case, the appropriate handler. It might be nice to use a union here to distinguish the two. For the jitter, this gets set by buildStackTrace in stackTrace.c: info[cnt].pc = STACKTRACEPC(trace); So, it uses the return pc found in the stack trace, which corresponds to the next instruction to execute. er, spoke too quickly. For a synchronous interrupt and subsequent exception, this will be the current instruction. But, for a regular throw, it will be the next pc. Hmm... that's the next *native* instruction. That's not necessarily the next bytecode instruction. (I imagine it usually happens to be so, though.) Alas, i seemed to have missed something in i386/jit.h: /* Extract the PC FP from the given frame */ #define PCFRAME(f) ((f)-retpc-1) #define FPFRAME(f) ((f)-retbp) So, when it gets pc its returning a pointer to the previous instruction. An x86 'call' is just one byte right? So, i guess that was working correctly and the EXCEPTIONFRAME macro is wrong. But, the i386 freebsd and linux exception frame initializers add a one to the current pc: /* Get the first exception frame from a signal handler */ #define EXCEPTIONFRAME(f, c) \ (f).retbp = (c)-sc_ebp;\ (f).retpc = (c)-sc_eip + 1 Ugh. I wonder if that was added to get around this exception problem? (that line is from March `98) Anyway, adding 1 to an x86 EIP isn't always going to point to a real instruction is it? nope It seems that the regular throw JIT case is the only one where we might have trouble getting the current PC (since the STACKTRACEPC() macro pulls the return code off the stack which is probably the first native instruction of the next bytecode). Seems to me that the right thing to happen is to fix that up with some magic and a comment, and have all the other cases record the current pc directly. Indeed, lets list the changes: Your fix for the exception range check. All EXCEPTIONFRAME() macros should set retpc to the current pc and not add one to it. Maybe make the pc field in vmException a union to clarify its use. Add a test, this is a bit complicated since you need an exception to be thrown on the very edge of the exception range. Add some bloody comments Also, grepping for end_pc turns up this code in checkCaughtExceptions in jit/machine.c /* include only if exception handler range matches pc */ if (meth-exception_table-entry[i].start_pc pc || meth-exception_table-entry[i].end_pc = pc) continue; Now, that doesn't look right to me... Heh, that's funny. Should the old jit just be removed from the current version? Do any architectures use it? i think a couple of platforms still use it... -Pat tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: flestmail - daily - 365/365 passed (100.0%) (0 errors, 0 failures)
--- Timothy Stack [EMAIL PROTECTED] wrote: On Tuesday, September 17, 2002, at 10:52 PM, Patrick Tullmann wrote: Heh, that's funny. Should the old jit just be removed from the current version? Do any architectures use it? i think a couple of platforms still use it... sparc-solaris and arm-linux use the old jit (it does not get through the class library compile on arm though). pocketlinux source tree includes jit3 versions for both, if someone wants to port it over to kaffe. cheers, dalibor topic __ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: flestmail - daily - 365/365 passed (100.0%) (0 errors,0 failures)
Patrick Tullmann wrote:
I was reading the VM spec last night, and it says that the end of an
exception range is exclusive, vs. the start being inclusive. Since
that's exactly what's happening (the exception is being re-tossed at
the very end of the coverage), I changed:
if (pc start_pc || pc end_pc) {
continue;
}
to:
if (pc start_pc || pc = end_pc) {
continue;
}
in the loop over the available exception handlers in
findExceptionBlockInMethod. This fixed the problem. However, that
comparison hasn't been touched since December `98. I have a hard time
believing the interpreter has never encountered this situation
before... (Perhaps the end_pc's were fixed up elsewhere at some
point?)
Hmm compiling it with kcj 'Version 2.1B released 17. July 2002' or
jikes 'Version 1.13 3/1/2001' doesn't make any difference... Also,
Sun's JDK1.4 can complete either compiled version of the test just
fine.
odd, i'm pretty sure it worked with a jikes v1.14 compiled file
So, I think that's the fix. I'm still wary because I wonder why it
ever worked... :)
noone uses intrp :) Which raises the question, why does it work fine
for the jitter and not intrp?
So, lets try and reexamine the whole thing...
First, what does the pc in the parameter list correspond to? The
current pc or the next pc?
For intrp, this gets set by runVirtualMachine intrp/machine.c:
register uintp pc = npc;
assert(npc meth-c.bcode.codelen);
mjbuf-pc = pc;
npc = pc + insnLen[code[pc]];
and read by dispatchException in exception.c:
/* Look for handler */
res = findExceptionBlockInMethod(frame-pc,
eobj-base.dtable-class,
frame-meth, einfo);
So, it uses the pc of the currently executing instruction...
For the jitter, this gets set by buildStackTrace in stackTrace.c:
info[cnt].pc = STACKTRACEPC(trace);
and read by unwindStackFrame in exception.c:
meth = findExceptionInMethod(frame-pc, class, einfo);
So, it uses the return pc found in the stack trace, which corresponds to
the next instruction to execute. Oops... Maybe we should change the
intrp engine to set mjbuf-pc to npc and see if that fixes it.
Also, grepping for end_pc turns up this code in checkCaughtExceptions
in jit/machine.c
/* include only if exception handler range matches pc */
if (meth-exception_table-entry[i].start_pc pc ||
meth-exception_table-entry[i].end_pc = pc)
continue;
Now, that doesn't look right to me...
-Pat
tim stack
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: flestmail - daily - 365/365 passed (100.0%) (0 errors,0 failures)
Timothy Stack wrote: For the jitter, this gets set by buildStackTrace in stackTrace.c: info[cnt].pc = STACKTRACEPC(trace); So, it uses the return pc found in the stack trace, which corresponds to the next instruction to execute. er, spoke too quickly. For a synchronous interrupt and subsequent exception, this will be the current instruction. But, for a regular throw, it will be the next pc. But, the i386 freebsd and linux exception frame initializers add a one to the current pc: /* Get the first exception frame from a signal handler */ #define EXCEPTIONFRAME(f, c)\ (f).retbp = (c)-sc_ebp;\ (f).retpc = (c)-sc_eip + 1 tim stack again, tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: flestmail - daily - 365/365 passed (100.0%) (0 errors, 0 failures)
[infinite exception dispatch loops] So, lets try and reexamine the whole thing... First, what does the pc in the parameter list correspond to? The current pc or the next pc? Ah, didn't think of that... glad you did though. You took a simple problem and exposed it for the nasty mess that at it is... hmm... maybe I prefered ignorance... :) Anyway, I would expect the pc passed to findExceptionBlockInMethod to be the current pc (i.e, the point where the exception occured). I think code that passes in something else is probably broken, right? Oops... Maybe we should change the intrp engine to set mjbuf-pc to npc and see if that fixes it. Wouldn't that break the code that jumps to an exception handler and re-sets the PC based on the exception handler? For the jitter, this gets set by buildStackTrace in stackTrace.c: info[cnt].pc = STACKTRACEPC(trace); So, it uses the return pc found in the stack trace, which corresponds to the next instruction to execute. er, spoke too quickly. For a synchronous interrupt and subsequent exception, this will be the current instruction. But, for a regular throw, it will be the next pc. Hmm... that's the next *native* instruction. That's not necessarily the next bytecode instruction. (I imagine it usually happens to be so, though.) But, the i386 freebsd and linux exception frame initializers add a one to the current pc: /* Get the first exception frame from a signal handler */ #define EXCEPTIONFRAME(f, c) \ (f).retbp = (c)-sc_ebp;\ (f).retpc = (c)-sc_eip + 1 Ugh. I wonder if that was added to get around this exception problem? (that line is from March `98) Anyway, adding 1 to an x86 EIP isn't always going to point to a real instruction is it? It seems that the regular throw JIT case is the only one where we might have trouble getting the current PC (since the STACKTRACEPC() macro pulls the return code off the stack which is probably the first native instruction of the next bytecode). Seems to me that the right thing to happen is to fix that up with some magic and a comment, and have all the other cases record the current pc directly. Also, grepping for end_pc turns up this code in checkCaughtExceptions in jit/machine.c /* include only if exception handler range matches pc */ if (meth-exception_table-entry[i].start_pc pc || meth-exception_table-entry[i].end_pc = pc) continue; Now, that doesn't look right to me... Heh, that's funny. Should the old jit just be removed from the current version? Do any architectures use it? -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Success means never having to wear a suit. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
