|
From: Chris J. <ch...@at...> - 2005-02-03 21:17:56
|
> On Thu, 2005-02-03 at 14:33 +1100, Steve Blackburn wrote: > > In Jikes RVM we generate a number of software traps using the INT=20 > > instruction. > > These are int 40 through to int 43. We use these to catch=20 > conditions such as=20 > > array bounds violations, throw control to a signal handler=20 > which then starts our=20 > > (Java) execption handling mechanism. So, yes, we do use=20 > these, and we catch=20 > > them in a regular signal hanler. >=20 > Oh, OK, I see. >=20 > > Perhaps all that needs to be done is for valgrind to implemetn the=20 > > behavior you > > describe above: make it look like a SIGSEGV. >=20 > Right, that's easy. I don't think you can tell from the=20 > signal info alone which int instruction it was, so we can=20 > easily simulate the effect of them all by calling a helper=20 > with, say, INT $99 in it. Hm, need to make sure that all the=20 > VCPU state is up to date at that point, so you can see it=20 > from the signal handler. Do you look at other CPU state from=20 > the handler, or just EIP? Do you expect to be able to=20 > continue after the INT instruction, or does it always raise a=20 > Java exception? I think the breakpoints patch I've posted to this list could be = informative here since it handles INT $3. The same principles could be extended to handle other interrupts. Basically what the patch does is translate the = trap instruction into code to return from the innerloop with a particular TRC value. This value is then caught in VG_(scheduler) which raises a real signal (SIGTRAP in this case). Raising a real signal has the benefit it = can be seen by a debugger. Chris |