From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21299 invoked by alias); 15 Nov 2011 07:01:21 -0000 Received: (qmail 21286 invoked by uid 22791); 15 Nov 2011 07:01:20 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,FROM_12LTRDOM 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; Tue, 15 Nov 2011 07:01:07 +0000 Received: from nat-jpt.mentorg.com ([192.94.33.2] helo=PR1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RQD10-0006SI-FR from Yao_Qi@mentor.com for gdb-patches@sourceware.org; Mon, 14 Nov 2011 23:01:06 -0800 Received: from [127.0.0.1] ([172.16.63.104]) by PR1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Nov 2011 16:01:04 +0900 Message-ID: <4EC20E2E.6010402@codesourcery.com> Date: Tue, 15 Nov 2011 07:01:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1 MIME-Version: 1.0 To: "gdb-patches@sourceware.org ml" Subject: [patch 0/5] pending tracepoint Content-Type: text/plain; charset=UTF-8 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: 2011-11/txt/msg00374.txt.bz2 Hi, `pending tracepoint' is quite similar to `pending breakpoint', that is, tracepoint locations are unknown at first, so they are `pending' there. Once locations are resolved, they are downloaded to inferior and installed. As this patch set below goes into trunk, it becomes relatively straightforward to support pending tracepoint. [patch 0/8] Download tracepoint locations when tracing is running http://sourceware.org/ml/gdb-patches/2011-11/msg00168.html GDB has to allow to create `pending tracepoint', just similar to creating pending breakpoint. GDB has to take care of validation of pending fast tracepoint. This is done by patch 2/5. Although tracepoint works with GDB disconnected, resolution to `pending tracepoint' need GDB connected, so GDB will emit a warning when disconnect from remote stub while there are still some pending tracepoints. This is done by patch 3/5. Patch 4/5 and 5/5 are about test cases and documentation changes respectively. Regression tested on x86_64-linux. Once this patch set goes into trunk, `pending tracepoint' work is done, but there is still one extended work, "validate pending fast tracepoint when it is resolved". It can be divided into two parts, 1) validate fast tracepoint on location level, and keep acceptable locations. What we are doing now is that validate each location of a tracepoint, if one of locations doesn't meet requirements, the tracepoint can't be created. It is a little too conservative. We can change this model to "create location for tracepoint if it meets requirements". This is not about `pending tracepoint' at all. 2) validate fast tracepoint locations when they are resolved, only adding locations meet requirements into tracepoint. I'll send patches out this week. -- Yao (齐尧)