From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21104 invoked by alias); 17 Nov 2011 12:28:40 -0000 Received: (qmail 21089 invoked by uid 22791); 17 Nov 2011 12:28:38 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 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; Thu, 17 Nov 2011 12:28:21 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RR14m-0006PF-7p from pedro_alves@mentor.com ; Thu, 17 Nov 2011 04:28:20 -0800 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Nov 2011 12:28:18 +0000 From: Pedro Alves To: Yao Qi Subject: Re: [patch 5/5] Document Date: Thu, 17 Nov 2011 12:28:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-12-generic; KDE/4.7.2; x86_64; ; ) Cc: gdb-patches@sourceware.org, Eli Zaretskii , Luis Machado References: <4EC20E2E.6010402@codesourcery.com> <201111161903.18043.pedro@codesourcery.com> <4EC47E7F.2090202@codesourcery.com> In-Reply-To: <4EC47E7F.2090202@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201111171228.16603.pedro@codesourcery.com> 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/msg00470.txt.bz2 On Thursday 17 November 2011 03:24:47, Yao Qi wrote: > +until they are resolved. The resolution of pending tracepoints requires > +@value{GDBN} support--in the remote target, when @value{GDBN} I think it really needs to be three dashes. > +disconnects from the remote stub, pending tracepoints still exist but > +can not be resolved while @value{GDBN} is disconnected. Sorry to be picky, but I'm trying to read this from a user's perspective, and it still confuses me. What does "pending tracepoints still exist" mean? Do you mean they still exist in GDB? That's true for all kinds of breakpoints, so it doesn't add anything. If you mean that they exist on the target, then what does it mean for a pending tracepoint to exist on the target? What we're really trying to say is that pending tracepoints don't work with disconnected tracing. How about: The resolution of pending tracepoints requires @value{GDBN} support--- when debugging with the remote target, and @value{GDBN} disconnects from the remote stub (@pxref{disconnected tracing}), pending tracepoints can not be resolved (and downloaded to the remote stub) while @value{GDBN} is disconnected. ? -- Pedro Alves