From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15535 invoked by alias); 16 Jan 2013 08:31:52 -0000 Received: (qmail 15430 invoked by uid 22791); 16 Jan 2013 08:31:50 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,SARE_SUB_OBFU_Q1 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Jan 2013 08:31:18 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1TvOOz-0005QT-5u from Yao_Qi@mentor.com ; Wed, 16 Jan 2013 00:31:17 -0800 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jan 2013 00:31:16 -0800 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.1.289.1; Wed, 16 Jan 2013 00:31:16 -0800 Message-ID: <50F66529.3090605@codesourcery.com> Date: Wed, 16 Jan 2013 08:31:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Pedro Alves CC: Subject: Re: [PATCH,gdbserver] Put 'multiprocess+' in to qSupported reply if GDB supports multiprocess References: <1358240468-11484-1-git-send-email-yao@codesourcery.com> <50F5B421.8040605@redhat.com> In-Reply-To: <50F5B421.8040605@redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-01/txt/msg00328.txt.bz2 On 01/16/2013 03:55 AM, Pedro Alves wrote: > I disagree, and it's a dangerous path to follow. It may prove useful > to know what exactly does a target support even if your gdb doesn't > support it for instance, as a debugging aid. Or GDB itself may know > of a feature, but choose to not enable it (and therefore not broadcast > support in its qSupported), but still infer something about the > target from the target's reported features. So it's more prudent to I can't figure out why GDB wants/has to know all features that GDBserver supports, even some of features are not supported by GDB. I don't find out a case that GDB has to lie to GDBserver, that GDB doesn't know about feature FOO, but is still interested in the feature FOO internally. > make the qSupported reported features as stateless as possible. Once we start to add features into qSupported packet (sent from GDB to GDBserver), the qSupoorted reply became stateful. If the qSupported reply is exactly about what the remote target supports, GDB doesn't to tell GDBserver what features GDB supports by means of qSupported. b.t.w, GDBserver only puts ";FastTracepoints+" into qSupported reply if both GDB sends "qRelocInsn+" and the target supports fast tracepoints. This issue jumps into my eyes when I think about the query of supported notifications on both sides. Both GDB and GDBserver knows different notifications and each of them should know what notifications supported in the other side. The protocol design is as follows: Supposing GDB knows notification N1, N2, and N3, while GDBserver knows notification N1, N2, and N4. --> qSupported:notifications=N1,N2,N3; <-- XXX;Notificaitons=N1,N2; as a result, GDBserver knows N3 is not supported by GDB, so doesn't send it. In the RSP interaction, I thought GDBserver doesn't have to tell GDB that GDBserver supports N4. What do you think? -- Yao (齐尧)