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
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Sat, 09 Feb 2008 10:47:15 +0200
- Subject: Re: RFC: Allow a wrapper when starting programs
- References: <20080208185727.GA30185@caradoc.them.org>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Fri, 8 Feb 2008 13:57:27 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>
>
> This patch allows GDB and gdbserver to use wrapper programs when they
> launch an inferior process.
Thanks!
A few comments on your patch:
> --- NEWS 7 Feb 2008 19:23:10 -0000 1.256
> +++ NEWS 8 Feb 2008 18:46:39 -0000
This part is okay, except:
> +* New features in the GDB remote stub, gdbserver
> +
> + - AltiVec and SPE registers on PowerPC targets are now accessible.
> +
> + - Thread debugging is now supported on GNU/Linux targets even when
> + the libthread_db library is missing.
> +
> + - The new file transfer commands (remote put, remote get, and remote
> + delete) are supported with gdbserver.
You are already describing gdbserver changes, so saying that again at
the end of the last sentence is redundant, I think.
> --- 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.
> + 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.
> +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.
> + The wrapper
> +will run until its first debug trap before @value{GDBN} gains 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. For
> +example, you can use @code{env} to pass an environment variable to the
> +debugged program, without setting the variable in @code{gdbserver}'s
> +environment:
Same here.