From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15259 invoked by alias); 24 Aug 2012 02:26:09 -0000 Received: (qmail 15174 invoked by uid 22791); 24 Aug 2012 02:26:08 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,FROM_12LTRDOM,KHOP_RCVD_UNTRUST,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; Fri, 24 Aug 2012 02:25:54 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1T4jar-0003vp-1h from Yao_Qi@mentor.com for gdb-patches@sourceware.org; Thu, 23 Aug 2012 19:25:53 -0700 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Aug 2012 19:25:52 -0700 Received: from qiyao.dyndns.org.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; Thu, 23 Aug 2012 19:25:51 -0700 From: Yao Qi To: Subject: [RCF 0/4] A general notification in GDB RSP Date: Fri, 24 Aug 2012 02:26:00 -0000 Message-ID: <1345775139-13576-1-git-send-email-yao@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain 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/msg00703.txt.bz2 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.