From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10820 invoked by alias); 8 Aug 2012 13:26:22 -0000 Received: (qmail 10810 invoked by uid 22791); 8 Aug 2012 13:26:21 -0000 X-SWARE-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL 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, 08 Aug 2012 13:26:08 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1Sz6H1-0002Hv-Nz from Yao_Qi@mentor.com for gdb-patches@sourceware.org; Wed, 08 Aug 2012 06:26:07 -0700 Received: from SVR-ORW-FEM-02.mgc.mentorg.com ([147.34.96.206]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Aug 2012 06:26:07 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.1.289.1; Wed, 8 Aug 2012 06:25:47 -0700 From: Yao Qi To: CC: Hui Zhu Subject: Re: [RFC] Autoload-breakpoints new version [3/9] notification async Date: Wed, 08 Aug 2012 13:26:00 -0000 Message-ID: <1866631.Ri6KkAT9H2@qiyao.dyndns.org> User-Agent: KMail/4.8.3 (Linux/3.3.7-1.fc16.i686; KDE/4.8.3; i686; ; ) In-Reply-To: <5020BF3A.8030809@mentor.com> References: <5020BF3A.8030809@mentor.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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: 2012-08/txt/msg00254.txt.bz2 On Tuesday, August 07, 2012 03:09:46 PM Hui Zhu wrote: > This patch is the extend for the notification function. > Current notification function cannot handle the packet when GDB doesn't w= ant > to send or receive packet from the remote target. This patch do the extend > make GDB can handle the notification even if it doesn't send or receive > packet. I am trying to understand what current GDB can do, and what patched GDB can= =20 do. If I understand it correctly, - current GDB only handle notification when it sends or receives packets - patched GDB can handle notification at any time when notification comes= =20 in. Looks this patch changes the way of GDB handling notifications (from "only-= on- send-receive" handling to "anytime" handling), but has nothing to do with h= ow=20 notification is sent out from remote stub. If so, why do you add=20 "NotificationAsync" in remote_supported_packet? Remote supported packets a= re=20 used to tell GDB what feature remote stub has or doesn't have. In other=20 words, "NotificationAsync" is a feature of GDB, instead of remote stub, so = we=20 don't need "NotificationAsync". I applied patch 1/9 and 3/9, and get following regressions in gdbserver wit= h=20 async mode on. FAIL: gdb.mi/mi-nonstop-exit.exp: finished exec continue (unknown output= =20 after running) FAIL: gdb.mi/mi-nonstop-exit.exp: finished exec continue (2) (unknown out= put=20 after running) FAIL: gdb.mi/mi-nsmoribund.exp: resume all, waiting for program exit=20 (timeout) --=20 Yao (=E9=BD=90=E5=B0=A7)