From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14095 invoked by alias); 24 Aug 2012 17:53:10 -0000 Received: (qmail 14080 invoked by uid 22791); 24 Aug 2012 17:53:07 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 24 Aug 2012 17:52:49 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q7OHqm0o019649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Aug 2012 13:52:48 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q7OHqkSf004578; Fri, 24 Aug 2012 13:52:47 -0400 Message-ID: <5037BF6E.3040407@redhat.com> Date: Fri, 24 Aug 2012 17:53:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [RCF 0/4] A general notification in GDB RSP References: <1345775139-13576-1-git-send-email-yao@codesourcery.com> In-Reply-To: <1345775139-13576-1-git-send-email-yao@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00755.txt.bz2 On 08/24/2012 03:25 AM, Yao Qi wrote: > Hi, > We have more and more requirements that remote target wants to notify > GDB via RSP at any time during connection when some states are changed > in remote target. However, GDB doesn't have such general notification > infrastructure. This is what this patch set tries to add. > > Nowadays, notification mechanism exists in GDB for '%Stop' only, > and works pretty good. My rationale of this work is 'decouple > %Stop/vStopped from existing notification mechanism so that > notification mechanism can handle other types of notification. > > First of all, let us look at how '%Stop' and 'vStopped' works, > > gdb gdbserver > <- %Stop // [1] Send notification > [after process other packets] > -> vStopped // [2] Ack this notification > <- T05 thread:2 // [3] Reply > -> vStopped // [4] Continue to query > <- OK // [5] Done > > We can generalize this protocol like this, > > gdb gdbserver > <- %NOTIF // [1] Send notification > [after process other packets] > -> vACK // [2] Ack this notification > <- REPLY // [3] Reply > -> vACK // [4] Continue to query > <- OK // [5] Done > > For each type of notification, we only have to define three things, > > 1) NOTIF, the key word of notification, for example, "Stop" > 2) ACK, the command GDB ack to this notification, "vStopped" for > example, > 3) REPLY, the format of reply to GDB. GDBserver should be able to > send packet to comply with REPLY, and GDB is able parse the packet, > and identify the packet is REPLY or not. > > Patch 1/4 is to create a general queue data structure which will not > only be used in patch 2/4 and 3/4, but also can be used in elsewhere > in GDB. > The patch 2/4 and 3/4 are to decouple %Stop and vStopped out of > existing notification, in order to make notification more general. > Patch 4/4 is to demonstrate how do we add a new type of notification > in the future, and test two types of notification work good > together. As you can see, it is relatively simple. Originally, I > intended to convert qTstatus to a new type of notification in patch > 4/4 as an example (when tracing status is changed, GDBserver sends > notification), but it takes time to think about it, so I post this > version here to get feedbacks first. > > All three patches are tested on x86_64-linux {native, gdbserver} x > {sync, async}. No regression. > > Note that the behaviour of notification in RSP is unchanged, that is > to say, patched GDB (w/ patch 2/4) works well with unpatched > GDBserver, and patched GDBserver (w/ patch 3/4) works well with > unpatched GDB. > > it is different from Hui's patch 3/9 in 'autload breakpoint' > patch series, > > [RFC] Autoload-breakpoints new version [3/9] notification async > http://sourceware.org/ml/gdb-patches/2012-08/msg00214.html > > His patch is to teach GDB to handle notification at anytime, while > mine is not, but to allow to add other types of notification similar > to existing %Stop/vStopped on the same infrastructure. I haven't read the patches in detail yet, but I'd like to say upfront that I like this very much. -- Pedro Alves