This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Wednesday, January 18 2017, I wrote:

> Hi again,


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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]