Re: RFC: Allow a wrapper when starting programs

Doug Evans
2008-02-09T19:20:07Z

On Feb 9, 2008 8:53 AM, Daniel Jacobowitz <drow@false.org> wrote:
> 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).

When explained this way one might think there are two wrappers: sh and
wrapper. Has anyone ever wanted a way to remove, replace, or
otherwise alter the use of the sh "wrapper"? I realize sh brings
certain functionality to the party, but it seems like one popular use
of the second wrapper is to work around the presence of the first
wrapper. It leaves me wondering if there's a better way. OTOH,
pragmatics may require the proposed implementation.