Re: [PATCH v2] Implement the ability to start inferiors with a shell on gdbserver

Sergio Durigan Junior
2017-01-26T22:47:56Z

On Wednesday, January 18 2017, I wrote:

> Hi again,

Ping.

> This is the second version of this patch series. I addressed many
> comments made by Luis, Eli, Tom and Pedro (private) on the first
> version. Thanks!
>
> 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