[PATCH v3 0/6] Implement the ability to start inferiors with a shell on gdbserver

[Sergio Durigan Junior <sergiodj at redhat dot com>]

Hi again,

This is the third version of this patch series.  I addressed the
comments made by Luis.

Here's what changed from v2:

 - Fixed many formatting nits (spurious newlines, indentation, etc.)

 - Added description of expected values by QStartupWithShell packet

Additionally, here's what changed from v1:

 - Added NEWS entry

 - Mentioned that the feature is to be used on UNIX-like systems

 - Removed third argument from set_executing

 - Removed 'set remote startup-shell' command

 - Renamed the packet to QStartupWithShell.  Now, the packet has only
   a boolean argument: "1" (meaning that the remote target should use
   a shell to start the inferior), and "0" (the remote target should
   not use a shell to start the inferior).

 - Write documentation for this new packet

 - Fixed and rewrote ChangeLog entries

 - Fixed spurious newlines on comments.

 - Fix comments that only mentioned "GDB" on files that are now being
   shared with gdbserver.

 - Adjust copyright notices on files

 - Use "untested" where applicable on the testcase


This patch series implement the "startup-with-shell" feature on
gdbserver.  This means that it will be possible to start inferiors
using the shell (instead of calling execv*), which brings many
advantages.

First of all, it will be possible to use I/O redirection, variable
substitution and globbing expansion on gdbserver just like we do today
on GDB.  This is great because, among other things, it brings
gdbserver on a pair with GDB when considering the Feature Parity
project.

Secondly, a great deal of code had to be shared between GDB and
gdbserver, especially the fork_inferior function, which means that now
both programs are using virtually the same code to start inferiors.
I've also had to touch on other areas, like terminal.h, inflow.c and
gdbthread.h, and even though only the APIs were shared (i.e.,
gdbserver's version of a gdbthread.h function may differ from GDB's
version), this is also beneficial in the long run when we start to
unify the code more deeply.  But I'm "raining in the wet" here; all
this has been explained in better terms before.

I did my best to split the patches, but unfortunately the
fork_inferior patch is big and I couldn't see a better way to do that.
But it shouldn't be very hard to review them, because most of it is
just "code movement".