This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: Allow a wrapper when starting programs
> 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?