This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/2] new memory-changed MI notification.
- From: dje at google dot com
- To: Yao Qi <yao at codesourcery dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, <gdb-patches at sourceware dot org>
- Date: Mon, 15 Oct 2012 10:58:25 -0700
- Subject: Re: [PATCH 1/2] new memory-changed MI notification.
- References: <1348793347-12556-1-git-send-email-yao@codesourcery.com> <1348793347-12556-2-git-send-email-yao@codesourcery.com> <87obkqt6ck.fsf@fleche.redhat.com> <5073D5B5.2060208@codesourcery.com>
Yao Qi writes:
> On 09/29/2012 01:17 AM, Tom Tromey wrote:
> > Usually I think it would be preferable to have a flag correspond to a
> > notification and not a command; but this would not work so well if a
> > command needed to suppress two different messages. (Though if that
> > happens then maybe we should have a slightly different approach based on
> > bitmasks.)
> >
>
> I agree with you that one flag should correspond to a notification. I
> revised my patch a little bit to get rid of suppression flag
> 'var_assign'.
Hi.
For my own education, is this suppression just an optimization, or is there a correctness issue here?
I can imagine that it's an optimization, why notify the frontend something changed when it's the frontend that requested the change.
But there is *zero* documentation in mi-main.h on *why* struct mi_suppress_notification exists, so it's hard to tell. :-(
[I realize your patch is just adding an entry, but I'd like to learn what the reason for it is.]