Re: RFC: Allow a wrapper when starting programs

[Daniel Jacobowitz <drow at false dot org>]

On Sat, Feb 09, 2008 at 06:40:48PM +0200, Eli Zaretskii wrote:
> 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.

Yeah.  Listing them is probably best.

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

Sure.  We're waiting for an extra trap for the same reason we
currently wait for two (on most systems; sometimes varies).  We
normally fork and then execute a command like this one:

  sh -c 'exec your-program'

The first trap is generated when gdb execs sh.  At this point we know
where the child is, but it's at the wrong place.  The loaded binary is
sh, not your-program, so we can't set breakpoints in your-program.

With a wrapper, we run:

  sh -c 'exec wrapper your-program'

So after two traps, the loaded program is wrapper.  If we gave
control to the user or tried to insert breakpoints at your-program's
symbols, things would go wrong.  We have to wait until the loaded
program is finally your-program.

There's no portable way to check what the loaded program is, and
even if there were it wouldn't help enough; wrapper and your-program
might be the same binary (a corner case, I admit).

-- 
Daniel Jacobowitz
CodeSourcery