Re: [MI non-stop 07/11, RFA] Allow all CLI command even if target is executing.

[Vladimir Prus <vladimir at codesourcery dot com>]

On Friday 11 July 2008 17:46:36 Pedro Alves wrote:
> 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.

I've of the same opinion. It seems to me that examining each and every command
is not quite practical. So, we either get to enable all commands and then disable,
or clarify error messages, or disable all commands, and enable those that actually
have to work. Enabling all commands seems safer, since the worst problem is inaccurate
error message.

- Volodya