[binutils-gdb] Introduce a serial interface for select'able events

[sergiodj+buildbot at sergiodj dot net]

*** TEST RESULTS FOR COMMIT 00340e1b916fa2d040439b101c220fae3c5834fa ***

Author: Pedro Alves <palves@redhat.com>
Branch: master
Commit: 00340e1b916fa2d040439b101c220fae3c5834fa

Introduce a serial interface for select'able events

This patch adds a new "event" struct serial type, that is an
abstraction specifically for waking up blocking waits/selects,
implemented on top of a pipe on POSIX, and on top of a native Windows
event (CreateEvent, etc.) on Windows.

This will be used to plug signal handler / mainline code races.

For example, GDB can indefinitely delay handling a quit request if the
user presses Ctrl-C between the last QUIT call and the next (blocking)
gdb_select call in the event loop:

      QUIT;
                  <<< press ctrl-c here and end up blocked in gdb_select
		      indefinitely.

      gdb_select (...); // whoops, SIGINT was already handled, no EINTR.

A global alone (either the quit flag, or the "ready" flag of the async
signal handlers in the event loop) is not sufficient.

To plug races such as these on POSIX systems, we have to register some
waitable file descriptor in the set of files gdb_select waits on, and
write to it from the signal handler.  This is classically a pipe, and
the pattern called the self-pipe trick.  On Linux, it could be a more
efficient eventfd instead, but I'm sticking with a pipe for
simplifity, as we need it for portability anyway.

(Alternatively, we could use pselect/ppoll, and block signals until
the pselect.  The latter is not a design I think GDB could use,
because we want the QUIT macro to be super cheap, as it is used in
loops.  Plus, Windows.)

This is a "struct serial" because Windows's gdb_select relies on that.
Windows's gdb_select, our "select" replacement, knows how to wait on
all kinds of handles (regular files, pipes, sockets, console, etc.)
unlike the native Windows "select" function, which can only wait on
sockets.  Each file descriptor for a "serial" type that is not
normally waitable with WaitForMultipleObjects must have a
corresponding struct serial instance.  gdb_select then internally
looks up the struct serial instance that wraps each file descriptor,
and asks it for the corresponding Windows waitable handle.

We could use serial_pipe() to create a "struct serial"-wrapped pipe
that is usable everywhere, including Windows.  That's what currently
python/python.c uses for cross-thread posting of events.

However, serial_write and serial_readchar are not designed to be
async-signal-safe on POSIX hosts.  It's easier to bypass those when
setting/clearing the event source.

And writing and a serial pipe is a bit heavy weight on Windows.
gdb_select requires an extra thread to wait on the pipe and several
Windows events, when a single manual-reset Windows event, with no
extra thread is sufficient.

The intended usage is simply:

- Call make_serial_event to create a serial event object.

- From the signal handler call serial_event_set to set the event.

- From mainline code, have select/poll wait for serial_event_fd(), in
  addition to whatever other files you're about to wait for.

gdb/ChangeLog:
2016-04-12  Pedro Alves  <palves@redhat.com>

	* Makefile.in (SFILES): Add ser-event.c.
	(HFILES_NO_SRCDIR): Add ser-event.h.
	(COMMON_OBS): Add ser-event.o.
	* ser-event.c, ser-event.h: New files.
	* serial.c (new_serial): New function, factored out from
	(serial_fdopen_ops): ... this.
	(serial_open_ops_1): New function, factored out from
	(serial_open): ... this.
	(serial_open_ops): New function.
	* serial.h (struct serial): Forware declare.
	(serial_open_ops): New declaration.