RE: [RFC] win32-nat.c 'set new-console' and interruption

["Pierre Muller" <muller@ics.u-strasbg.fr>]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Pedro Alves
> Envoyé : Monday, June 23, 2008 4:41 PM
> À : gdb-patches@sourceware.org
> Cc : Pierre Muller
> Objet : Re: [RFC] win32-nat.c 'set new-console' and interruption
> 
> A Monday 23 June 2008 15:23:06, Pierre Muller wrote:
> 
> > I have a proposal to remove that possible race condition:
> > The exception record has a field that contains the exception
> > address, if I test that there is no GDB inserted breakpoint at
> > that location before converting the TARGET_SIGNAL_TRAP
> > into a TARGET_SIGNAL_INT, it should fix most problems, no?
> >
> >   The one case that it would still not catch would be
> > a 'int 3' instruction that is in the debuggee code from the start
> > but other than at startup, such instructions are quite unlikely, no?
> >
> 
> IIRC, DebugBreakProcess injects a thread in the debuggee and
> always breaks at the same address / in the same function -- I don't
> know if there's a hardcoded 0xcc at the break address you
> could check, or if the exception is generated programatically,
> but at least you could conditionalize on the function name (if there's
> no hardcoded break, you still can't distiguish by name only a user
> break placed in that special break function)

  I checked this: on windows XP it does use an 'int 3' instruction
that is situated in ntdll DLL at an exported function named
DbgUiConnectToDbg, but I would really like to avoid hard-coding this into
win32-nat.c as there is no assurance that other versions of
Microsoft OS will use the same function.

> Another option is to use SuspendThread on all threads to stop
> the process, which is what I believe Visual Studio uses.
> gdbserver has that implemented for systems that don't have
> DebugBreakProcess.

That is also a nice idea...
The only problem in that case is, which thread do we then
use as the current_thread? 
Do we default on main_thread_id?
But the current win32-nat source code has a particularity
here: it never removes the main_thread_idd thread
even if that thread exits, I don't really know 
why it was coded like this but that means that using
main_thread_id might put us in a 'dead' thread.

  I never managed to send a patch for this, 
and I suspect that there are some hidden reason for
this strange behavior!

  We could insert code that stops all threads into
win32_wait at the location of the 
deprecated_ui_loop_hook code,
but I don't know really how to handle this:
if you suspend manually all threads, you can of course
set ourstatus, but the question is how do you coordinate this 
with the next call to win32_resume?
Is it enough to add a global variable
threads_suspended_manually (not sure this is the best name)
and to add something like
if (!threads_suspended_manually)
  res = ContinueDebugEvent (...)
else
  /* Here we add the code to resume all threads */

If fear that we might need more special code, for instance if
win32_resume is called with a non zero signal to pass,
which would of course be impossible in that case.

  I would personally prefer to postpone this 
to a later patch, but Christopher should 
tell us what the best way is.


Pierre Muller
Pascal language support maintainer for GDB