[kaffe] Re: flestmail - daily - 365/365 passed (100.0%) (0 errors, 0 failures)

[Patrick Tullmann]

[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                                       tullmann at cs.utah.edu
              Success means never having to wear a suit.