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

[Daniel Jacobowitz <drow@false.org>]

On Sat, Jun 28, 2008 at 08:55:45PM +0400, Vladimir Prus wrote:
> 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?
> 
> - Volodya
> 
> 	* gdb/top.c (execute_command_1): Don't check if the inferiour
> 	is running.

What does this do to the quality of error messages?  Particularly for
targets other than Linux, or targets with async but not non-stop.

It's true that we'll have to get rid of this eventually, but can we do
it without having to think about each command individually?

"ignore" is an interesting example.  If a breakpoint has been ignored
twice and you lower the ignore count to one while the target is
running do we need to stop?

-- 
Daniel Jacobowitz
CodeSourcery