Re: RFC: Allow a wrapper when starting programs

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 9 Feb 2008 10:48:34 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sourceware.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?

Maybe, but it's better not to create an impression that this is
supported universally.  To make the burden easier, we could say
something like "this is supported by only some platforms".

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

DJGPP is not important enough to care, but Cygwin is, and so are (to a
lesser extent, I think) MinGW and NTO.

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

I agree; documenting the restriction in the manual should be good
enough.

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

Try me: if you explain why all this is needed, I might find a way to
describe that in the manual.  For starters, why do we need to wait for
an extra trap?