Re: RFC: Allow a wrapper when starting programs

Eli Zaretskii
2008-02-09T08:48:19Z

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