[gdbserver/wince] (7/11) Make the new interrupt method actually always work in WinCE

Pedro Alves pedro_alves@portugalmail.pt
Mon Nov 12 02:08:00 GMT 2007


Hi,

The new method to interrupt the inferior should work
on WinCE.

Surprisingly, when writing my first version of the interrupt
support patch, a few months ago, I noticed that very frequently
the inferior would just crash.  I could see that I was
always stopping inside a kernel call when it crashed.  After a
few nights of severe head banging, I noticed that I could
reproduce it with Microsoft's debugger, by simply touching
any register value before resuming.  Even if I didn't
change the value, that is, I set the same value as what
was already in the register, I would get an exact same crash.

So, what I can get from this, is that, unfortunatelly, a
SuspendThread call doesn't suspend the thread immediatelly.
Well, that is actually documented, but what isn't clear from
MSDN is that the SuspendThread call actually returns without
error in that case.  In the case that the thread is still
doing something on the kernel side, after the
SuspendThread call, the results of  calling GetThreadContext
will reflect the fact that the thread was still running.
To be clear:

DWORD suspend_count = SuspendThread (h);

(check that is doesn't return with error)

GetThreadContext (h, &context);
Sleep (1000);
GetThreadContext (h, &context); /* may return something different */
Sleep (1000);
GetThreadContext (h, &context); /* may return something different */
Sleep (1000);

Unfortunatelly, there is no way to know if the thread is finally
stopped.

Fortunatelly, I found that there is a register key that makes
the Microsoft's debugger spit a few interesting logs.  And there
it was.  There is no SetThreadContext call being done when resuming
the inferior, unless we force the context to change in the
register window.

So, what this patch does, is implement the same workaround MSFT's
debugger uses.  Don't set the context back to the inferior, unless
it has been explicitly changed by gdb or gdbserver.  Actually, it
is a little bit better, as it won't crash if the user sets some
register's contents back to what it was when the inferior stopped.

Cheers,
Pedro Alves


-------------- next part --------------
A non-text attachment was scrubbed...
Name: set_thread_context_if_changed.diff
Type: text/x-diff
Size: 3639 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20071112/9a42a81b/attachment.bin>


More information about the Gdb-patches mailing list