Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Vladimir Prus <vladimir@codesourcery.com>
Subject: Re: [MI non-stop 07/11, RFA] Allow all CLI command even if target is executing.
Date: Fri, 11 Jul 2008 13:46:00 -0000	[thread overview]
Message-ID: <200807111446.36378.pedro@codesourcery.com> (raw)
In-Reply-To: <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


  reply	other threads:[~2008-07-11 13:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-28 16:58 Vladimir Prus
2008-07-11 13:46 ` Pedro Alves [this message]
2008-07-11 18:59   ` Vladimir Prus
2008-07-11 19:04     ` Daniel Jacobowitz
2008-07-11 19:12       ` Pedro Alves
2008-07-13  4:26       ` Daniel Jacobowitz
2008-07-13  4:35         ` Vladimir Prus
2008-07-11 13:46 ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200807111446.36378.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=vladimir@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox