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

[Sergio Durigan Junior <sergiodj@redhat.com>]

On Tuesday, February 07 2017, I wrote:

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

Ping.

> 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".

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/