|
From: Chris J. <ch...@at...> - 2005-02-04 20:38:53
|
> On Fri, 2005-02-04 at 09:16 +0000, Chris January wrote: > > > Actually, that's what my patch does, only much more simply. > > > It calls a helper which invokes a real int3 instruction; the=20 > > > generated SIGTRAP is then delivered to the thread using the=20 > > > normal signal machinery. > >=20 > > Doesn't that mean %eip isn't in the baseBlock/VG_(threads) at=20 > > exception time? >=20 > The INT/ud2 instructions are considered to be the end of the=20 > basic block, so all the VCPU state is flushed out. EIP will=20 > point to the client's INT instruction (so it doesn't matter=20 > what kind of INT we use to raise the signal, so long as it=20 > raises the right kind of signal). Sorry, maybe I'm not looking at your patch correctly but I can't see how = the VCPU state is flushed out before the exception is generated. Could you explain please? As I understand it the VCPU state is only flushed after = the exception has occurred, the kernel has queued the SIGTRAP signal, = Valgrind has received the signal and longjmp'ed out of the scheduler. Any = external program monitoring the program looking for traps, for example, will see = the wrong instruction pointer, even if they look in the = baseBlock/VG_(threads) structure instead of the real regs. Chris |