Re: RFC: Allow a wrapper when starting programs

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Fri, 8 Feb 2008 13:57:27 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>
> 
> This patch allows GDB and gdbserver to use wrapper programs when they
> launch an inferior process.

Thanks!

A few comments on your patch:

> --- NEWS	7 Feb 2008 19:23:10 -0000	1.256
> +++ NEWS	8 Feb 2008 18:46:39 -0000

This part is okay, except:

> +* New features in the GDB remote stub, gdbserver
> +
> +  - AltiVec and SPE registers on PowerPC targets are now accessible.
> +
> +  - Thread debugging is now supported on GNU/Linux targets even when
> +  the libthread_db library is missing.
> +
> +  - The new file transfer commands (remote put, remote get, and remote
> +  delete) are supported with gdbserver.

You are already describing gdbserver changes, so saying that again at
the end of the last sentence is redundant, I think.

> --- fork-child.c	29 Jan 2008 21:11:24 -0000	1.38
> +++ fork-child.c	8 Feb 2008 18:46:39 -0000

Do all supported platform use fork-child to run the inferior?  If not,
those that don't will not have this feature, and this fact should be
reflected in the manual.

> +  if (exec_wrapper)
> +    pending_execs++;

You seem to be assuming that the wrapper is a simple command that
exec's only once.  But in fact the wrapper could be an arbitrarily
complex script that exec's several times, right?  If a single-exec
limitation is something we cannot easily overcome, we must document it
clearly in the manual.

> +void
> +_initialize_fork_child (void)
> +{
> +  add_setshow_filename_cmd ("exec-wrapper", class_run, &exec_wrapper, _("\
> +Set a wrapper for running programs."), _("\
> +Show the wrapper for running programs."), NULL,

That is rather cryptic, IMO.  How about adding a few more words about
what is a wrapper and how it is used?

> +                             The wrapper will run until its first
> +debug trap before @value{GDBN} takes control.
> +
> +On Unix systems, a debug trap (@code{SIGTRAP}) is generated at the
> +@code{execve} system call.  This allows any program which uses
> +@code{execve} to start another program to be used as a wrapper.

This is not detailed enough to be useful to anyone but a GDB hacker
who also happened to read the respective portions of the code in
fork-child.c.  In any case, it left me wondering what is this all
about, and why I, as a GDB user, should care about SIGTRAPs.

IOW, if this is important for the user to know, we should explain the
issue in terms understandable by a GDB user.

> +                                                           The wrapper
> +will run until its first debug trap before @value{GDBN} gains control.
> +
> +On Unix systems, a debug trap (@code{SIGTRAP}) is generated at the
> +@code{execve} system call.  This allows any program which uses
> +@code{execve} to start another program to be used as a wrapper.  For
> +example, you can use @code{env} to pass an environment variable to the
> +debugged program, without setting the variable in @code{gdbserver}'s
> +environment:

Same here.