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

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

On Sat, Feb 08, 2014 at 05:15:33PM +0400, Joel Brobecker wrote:
> > > One other possible option: Add a new option that would be available
> > > to all commands to disable notifications related to the command being
> > > executed. That way, FE could use it to reduce unnecessary back-chatter.
> > 
> > That is what I am thinking about.

I don't think the amout of information discussed here is worth any special
action on neither gdb's nor a frontend's side. Normal operation produce
"chatter" e.g. for library load/unload notifications on a much bigger
scale.

> > > I don't really like that option, though, as it would require a
> > > certain transition period.
> > 
> > What do you mean by "transition period"?  We can make use of
> > "-list-features" to tell FE that FE can disable/enable MI notifications
> > through a certain command.
> 
> The issue is people using older versions of an FE with a newer version of
> GDB. For those, their FE wouldn't know about the new option and thus get
> the notifications that they might not expect.

This happened regularly with other new notifications in the past
so I would expect frontends to be able to handle new notifications
gracefully. In this case "new" is even relative as the notifications
are sent in most circumstances already anyway.
 
> I don't know if we need to be concerned about this sort of compatibility
> or not...

Since it is not a concern when introducing new notifications like
=cmd-param-changed, =memory-changed or even =breakpoint-modified
itself and frontends need to handle the case of "unexpected" 
notifications anyway, it's hard for me to see how sending a specific
notification in all cases instead of in "most" cases can do harm.

Andre'