Hi,

(Some ramp-up first.)

Non-stop mode works on top of the asynchronous mode, because in non-stop mode,
you naturally want to be able to issue commands while the inferior is running.

One requirement of the asynchronous mode, is that instead of blocking in
target_wait waiting for the inferior to stop, the target registers a
waitable file descriptor in the event loop, that is written to whenever
the target has something to report to the core (say, a SIGTRAP).  This way,
the event loop continues running and handling CLI/MI commands while the
inferior is running.

The remote.c target registers the serial descriptor (actually a
`struct serial' interface) that is used to communicate with the remote
server to that effect.  This way, whenever there is communication going
in the server -> GDB direction, the event loop calls the associated
callback which ends up calling target_wait -> remote_wait to collect
the event the stub is reporting, and the immediatelly returns again to
the core, handling the event, and going back to the event loop.

For non-stop mode, however, I'll need two other event sources registered in
the event loop, that are independant of the remote communication, as you'll
see in the patch I'll post soon.  The easiest way to get us a select'able
file descriptor with the properties we want, is a pipe.  We register the
read end in the event loop, and write something to the write end whenever
we have something interesting to tell the core about.  This is what I've
done in the linux native implementation (linux-nat.c).

Now, the problem with remote.c, is that it is built on all hosts, and it
happens that on Windows, the file descriptors returned from `_pipe'
are not waitable on.  The handles behind them belongs to an anonymous pipe,
and WaitForMultipleObjects doesn't work on those.

Now, we already have infrastructure in place that abstracts a bunch
or serial interface types (serials, pipes, tcp, udp, etc.).  And
"target remote | " does work on Windows.  So, I though that the
best practical solution for this would be to reuse it.

That's what the attached patch does.

Without going much over the details of the remote non-stop
implementation, here's a snippet of how I intend to use it in
remote.c:

 /* Pipes for use by the asynchronous event processing used in non-stop
    mode.  */

 static struct serial *remote_inferior_event_pipe[2];
 static struct serial *remote_get_pending_events_pipe[2];

 static void
 make_event_pipes (void)
 {
   /* Create event pipes and register them in the event loop.  */
   if (serial_pipe (remote_inferior_event_pipe) == -1
       || serial_pipe (remote_get_pending_events_pipe) == -1)
     perror_with_name(_("Creating non-stop event files failed"));

   /* Register the read handles in the event loop.  */
   serial_async (remote_inferior_event_pipe[0],
 		remote_async_inferior_event_handler, NULL);
   serial_async (remote_get_pending_events_pipe[0],
 		remote_async_get_pending_events_handler, NULL);
 }

Calling serial_open to open a pipe doesn't cut it, because that is
designed to spawn a child process and communicate with it through
pipes.  I don't want to spawn a new process, and I want both ends
of the pipe.  To that end, I've added a new function `gdb_pipe' to
ser-go32.c, ser-ming32.c and ser-pipe.c, which should satisfy the
linking on all possible hosts:

configure.ac:
 dnl Figure out which of the many generic ser-*.c files the _host_ supports.
 SER_HARDWIRE="ser-base.o ser-unix.o ser-pipe.o ser-tcp.o"
 case ${host} in
   *go32* ) SER_HARDWIRE=ser-go32.o ;;
   *djgpp* ) SER_HARDWIRE=ser-go32.o ;;
   *mingw32*) SER_HARDWIRE="ser-base.o ser-tcp.o ser-mingw.o" ;;
 esac
 AC_SUBST(SER_HARDWIRE)

For go32/djgpp or for unix hosts that don't have socketpair, I
just bail out with ENOSYS.

I few other tweaks were needed, because I needed a way
for serial_fdopen to call into the serial_ops implementation to
do some initialisations.  Anyway, the end result is a new
shiny function called:

 int serial_pipe (struct serial *scbs[2]);

That the remote.c code can use, so it can stay agnostic of
which host is building it.

Anyone see a better way to do this?  Does it sound reasonable?

-- 
Pedro Alves