Re: RFC: Allow a wrapper when starting programs

[Daniel Jacobowitz <drow@false.org>]

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.

-- 
Daniel Jacobowitz
CodeSourcery