This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [MI non-stop 07/11, RFA] Allow all CLI command even if target is executing.
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Vladimir Prus <vladimir at codesourcery dot com>
- Date: Fri, 11 Jul 2008 14:46:36 +0100
- Subject: Re: [MI non-stop 07/11, RFA] Allow all CLI command even if target is executing.
- References: <200806282055.45829.vladimir@codesourcery.com>
A Saturday 28 June 2008 17:55:45, Vladimir Prus escreveu:
> There are several strategies to accepting commands when inferior_ptid is
> running. One approach is to plain disallow all commands when inferior_ptid
> is running. This seems too strict. Clearly, setting ignore count of
> a breakpoint does not require any access to the target at all. Another
> approach is to document which commands may be allowed when the target is
> running. The problem is that each individual command may work or not work
> depending on the properties of the target.
>
> So, it's better to allow all commands up-front, and emit an error if we
> try an operation that the current target does not allow. This way, we'll
> never mistakenly prevent an operation that the target actually can perform.
> In case of error, the frontend may show the error to the user, and user
> change either change his mind, or explicitly stop a thread, or ask the
> frontend to implicitly interrupt the target, or ask gdb to do same.
>
> OK?
>
I think this is the right direction.
In many cases, the error that will come out of the target is just
plain non-sense, so we should catch the offensive command earlier
if possible. E.g., reading registers from a running thread in linux
will error out with the same error as if the thread does not exist
at all, a very confusing error.
I even added the infrun.c:ensure_not_running function and its calls
to that effect.
Since only non-stop is affected by this, I think it's a sane direction.
Then we get to protect commands or make the targets throw more reasonable
errors as we find them. Better than releasing GDB to users with non-stop,
then having them not being able to execute some command simply because
we forgot to that it as "safe".
The other perspective is that there will be surelly code paths that
may bork as not expecting an exception, hence the cleanups may not
be setup correctly. But, those are bugs we should fix anyway.
> - Volodya
>
> * gdb/top.c (execute_command_1): Don't check if the inferiour
> is running.
> ---
> gdb/top.c | 8 --------
> 1 files changed, 0 insertions(+), 8 deletions(-)
>
> diff --git a/gdb/top.c b/gdb/top.c
> index e09ccaa..a891a43 100644
> --- a/gdb/top.c
> +++ b/gdb/top.c
> @@ -444,14 +444,6 @@ execute_command_1 (char *p, int from_tty, int
> internal) && !get_cmd_no_selected_thread_ok (c))
> error (_("\
> Cannot execute this command without a selected thread. See `help
> thread'")); - /* If the target is running, we allow only a limited set
> of - commands. */
> - else if (target_can_async_p ()
> - && target_has_execution
> - && ((!non_stop && any_running ())
> - || (non_stop && is_running (inferior_ptid)))
> - && !get_cmd_async_ok (c))
> - error (_("Cannot execute this command while the target is running."));
>
> /* Pass null arg rather than an empty one. */
> arg = *p ? p : 0;
--
Pedro Alves