This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [PATCH 1/5] Add annex in a async remote notification.

From: Yao Qi <yao at codesourcery dot com>
To: Eli Zaretskii <eliz at gnu dot org>
Cc: <gdb-patches at sourceware dot org>
Date: Sat, 30 Mar 2013 00:17:48 +0800
Subject: Re: [PATCH 1/5] Add annex in a async remote notification.
References: <1358838232-13319-1-git-send-email-yao at codesourcery dot com> <1358838232-13319-2-git-send-email-yao at codesourcery dot com> <83fw1tod6e dot fsf at gnu dot org> <511EFE76 dot 4030506 at codesourcery dot com> <83621ssj6n dot fsf at gnu dot org>

[Eli, sorry for missing this mail. Find it hide in the thread when Ihave a chance to revisit this patch series.]


On 02/16/2013 05:26 PM, Eli Zaretskii wrote:

Sorry, I don't follow your reasoning.

My concern was about the following use case:

   . an old MI client that only supports the old "name:event" form

   . a notification is sent in the new form "name:annex:event"

   . the MI client only parses the first 2 parts, and confuses "annex"
     for "event"

How can we be sure this can never happen?  We have no idea what MI
clients are out there, they are out of control of GDB development.

Patch 2/5 (Query supported notifications by qSupported) is to addressthis issue. When GDB connects to the remote stub, they will exchangethe supported annexes. As a result, the new form "name:annex:event"shouldn't be sent out if the other side doesn't support it. Does itanswer your question?


--
Yao (éå)

Follow-Ups:
- Re: [PATCH 1/5] Add annex in a async remote notification.
  - From: Eli Zaretskii

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]