Re: [PATCH] Test no =breakpoint-modified is emitted for modifications from MI commands

[andre <apoenitz@t-online.de>]

On Fri, Feb 07, 2014 at 05:12:06PM +0800, Yao Qi wrote:
> On 02/07/2014 04:39 AM, andre wrote:
> > I understand the patch, but I do not understand the motivation behind
> > the design decision to not send notifications when the change is 
> > triggered by an MI command.
> > 
> 
> The rationale is mentioned here
> https://sourceware.org/ml/gdb-patches/2012-07/msg00487.html

Sure, but I don't understand it. You argue that it is necessary for a
frontend to keep track of changes triggered by manual user interaction.
That's fine. But it is unclear why this reasoning should only be 
applied to non-MI commands, and not for MI commands that a user enters
manually (and that gdb happily accepts).
 
> In short, we want MI frontend is aware of GDB's state changes, such as
> breakpoint changes.  If requested changes are from MI, MI frontend
> should be aware of them, so no notifications are sent.
> > To get reliable information about the actual gdb internal state in this
> > setup there are essentially three choices for a frontend developer:
> > 
> >  - prevent the user from entering MI commands in the console
> >    (and try to catch all possible workarounds to sneak in MI
> >    commands nevertheless),
> > 
> >  - pre-parse user input before sending it to gdb, try to recognize
> >    MI commands that are known to not produce notifications and
> >    interpret a ^done as "all fine according to whatever you currently
> >    think 'fine' means",
> > 
> >  - ignore =breakpoint-modified notification in general and try to get
> >    full information using other means.
> > 
> > None of these options is desirable. None would be needed if gdb in
> > MI mode would simply announce all (non-internal) breakpoint modifications
> > with =breakpoint-modified notifications.
> 
> #1 is fine to me.

But not for me. I don't want to needlessly restrict what my users are
allowed to type, or not. It might even e.g. be useful to copy/paste/modify 
previously sent MI commands and send them manually via the console. In your 
approach this would not be possible, or at least require the user to
re-write the full command in non-MI syntax. 

> It shouldn't be hard to do that.  On the other hand,
> I don't understand users have to input MI commands in console, which
> is provided to accept CLI commands.

The point is not that they should _have to_ use MI syntax, but that they
_could_ if they wish.

> > I would pretty much prefer notifications on all breakpoint changes in
> > MI mode, no matter whether they are initiated by an MI or a non-MI command.
> 
> That would be too noisy in some cases.

It's easier for a frontend to filter out messages (especially if they
are expected) than to act on messages that are not send. And it's not
that we are talking about millions of notifications here that might
the communication line.`

Andre'