Re: RFC: Allow a wrapper when starting programs

Daniel Jacobowitz
2008-02-09T15:48:58Z

On Sat, Feb 09, 2008 at 10:47:15AM +0200, Eli Zaretskii wrote:
> > --- 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.

I was wondering about that. Will keeping the list up to date be a
problem?

Every native (non-remote) target uses fork-child, except for DJGPP,
Cygwin, mingw32, and QNX NTO.

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

For a typical script, this isn't an issue. Forks are not caught, nor
are execs after forking. So this would work:

#!/bin/sh
touch /tmp/logfile
exec "$@" 2> my-stderr.txt

Of course, you could chain wrappers: "set exec-wrapper env env". And
GDB could make the number of traps configurable for that case. But I
don't think it's useful, and it's hard to explain. So I would prefer
not to support it until someone finds a way to take advantage of
chaining.

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

This is where I get stuck. I did the best I could, but the effect of
waiting for an extra trap is hard to describe except in terms of
signals or examples. I don't know what else to add.