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: Tom Tromey <tromey at redhat dot com>
- To: dje at google dot com
- Cc: Yao Qi <yao at codesourcery dot com>, <gdb-patches at sourceware dot org>
- Date: Mon, 15 Oct 2012 13:07:17 -0600
- 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> <20604.20161.315324.841784@ruffy2.mtv.corp.google.com>
>>>>> "Doug" == Douglas Evans <dje@google.com> writes:
Doug> For my own education, is this suppression just an optimization, or is
Doug> there a correctness issue here?
Doug> I can imagine that it's an optimization, why notify the frontend
Doug> something changed when it's the frontend that requested the change.
Doug> But there is *zero* documentation in mi-main.h on *why* struct
Doug> mi_suppress_notification exists, so it's hard to tell. :-(
Doug> [I realize your patch is just adding an entry, but I'd like to learn
Doug> what the reason for it is.]
I don't know about this case in particular, but in many cases in MI, a
command will have a result record that encodes the exact same data that
an async response would give. On the other hand, if a CLI command is
invoked, then there is no relevant response record, and so the async
response must be generated.
I think it is an optimization. Offhand I can't think of a correctness
issue here, but I guess I wouldn't be surprised if there is one lurking
for some command or another.
Tom