Re: Non-stop mode for Windows (mingw)

[Pedro Alves <palves@redhat.com>]

On 09/19/2016 07:25 AM, Raphael Zulliger wrote:
> According to empirical tests and by looking at the GDB sources,
> 'windows-nat.c' and, therefore, GDB running on Windows (mingw) does not
> support non-stop debugging.
> 
> - What's the technical reason behind this? Was it just not ported to
> that platform so far? 

This.

> Wasn't it done because it's tricky?

- What would be needed to support it?

First, implement "maint set target-async on" support.  That is,
support background execution commands, like "continue&", even
in all-stop mode.  non-stop mode requires target-async support.

This basically means two things:

#1 - Implement support for TARGET_WNOHANG in windows_wait, returning
  TARGET_WAITKIND_IGNORE when there's no event to process.

The easiest is to return TARGET_WAITKIND_IGNORE when WaitForDebugEvent
times out.  We currently loop locally instead.

#2 - Somehow wake up gdb's main event loop whenever there's a 
target event to process.

The easiest though least efficient way would be constantly force the event
loop to poll, by always calling mark_async_event_handler when windows_wait
is called.  Essentially, telling the event loop code that there's maybe
some event to process.  If there's no actually event to return, then #1
above kicks in.

You'd probably want to avoid the large time out inside windows_nat
though.  So I'd try passing 0 as time out time to WaitForDebugEvent,
to effect a real poll, and then use the event loop's timer events
support to poll at some frequency instead of constantly.

To avoid the polling you'd probably need to move the WaitForDebugEvent
calls to a separate thread.  You'd then install a waitable event in gdb's event
loop, which the WaitForDebugEvent thread would set.  You'd use serial_event
for this (gdb/ser-event.h), which is basically a thin wrapper around SetEvent.



Then for non-stop, you'll want to support debugging one stopped thread
while the others are left running.  The main problem I think is that
WaitForDebugEvent implicitly suspends all threads.  In principle, it might
be possible to SuspendThread the event thread and call ContinueDebugEvent
immediately after WaitForDebugEvent returns the event.  First change exception
handling and DBG_CONTINUE / DBG_EXCEPTION_NOT_HANDLED is an open
question then though.

> (Is the main required thing that
> 'displaced single stepping' is required for non-stop mode?)

No.  Non-stop can work correctly without that nowadays -- gdb pauses
all threads, removes a breakpoint, step the thread over the breakpoint,
and then re-resumes threads that were originally running.  So
displaced stepping is considered an optimization nowadays, rather
than a requirement.

In any case, the displaced stepping implementation is mostly
architecture-specific, rather than OS specific, so the x86 Windows port
just needs to wire in the existing x86 displaced stepping support.

Thanks,
Pedro Alves