This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Test no =breakpoint-modified is emitted for modifications from MI commands
- From: andre <apoenitz at t-online dot de>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Yao Qi <yao at codesourcery dot com>, gdb-patches at sourceware dot org
- Date: Sat, 8 Feb 2014 15:11:22 +0100
- Subject: Re: [PATCH] Test no =breakpoint-modified is emitted for modifications from MI commands
- Authentication-results: sourceware.org; auth=none
- References: <1390549587-23625-1-git-send-email-yao at codesourcery dot com> <52F381B0 dot 4010602 at codesourcery dot com> <20140206203936 dot GA7055 at klara dot mpi dot htwm dot de> <52F4A366 dot 6060704 at codesourcery dot com> <20140207161221 dot GA5150 at klara dot mpi dot htwm dot de> <20140208031854 dot GM5485 at adacore dot com> <52F5A67A dot 7010301 at codesourcery dot com> <20140208131533 dot GN5485 at adacore dot com>
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'