From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15262 invoked by alias); 17 Nov 2011 14:41:34 -0000 Received: (qmail 15251 invoked by uid 22791); 17 Nov 2011 14:41:32 -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 14:41:19 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RR39T-0003I3-4Z from pedro_alves@mentor.com ; Thu, 17 Nov 2011 06:41:19 -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 14:41:17 +0000 From: Pedro Alves To: Yao Qi Subject: Re: [patch 5/5] Document Date: Thu, 17 Nov 2011 14:41: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> <201111171228.16603.pedro@codesourcery.com> <4EC51A8D.8080007@codesourcery.com> In-Reply-To: <4EC51A8D.8080007@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201111171441.15620.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/msg00473.txt.bz2 On Thursday 17 November 2011 14:30:37, Yao Qi wrote: > On 11/17/2011 08:28 PM, Pedro Alves wrote: > >> > +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: > > > > I agree that "pending tracepoints still exist" is confusing, and we > should remove this sentence. However, I don't think we should express > "pending tracepoints don't work with disconnected tracing.", because, > "pending tracepoints" and "disconnected tracing" are orthogonal to each > other. A remote stub can support either/both/none of them. But if the target doesn't support disconnected tracing, tracing always stops on disconnection, and so mentioning that pending tracepoints don't resolve isn't interesting for that case. The ability to resolve or not pending tracepoints while gdb is disconnected is only interesting from the target's perpective _while_ a trace run is ongoing. From gdb's perspective, once the remote target goes away, there's nothing special about pending tracepoints compared to other types of breakpoints. > > 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 > > ...so I suggest remove "(@pxref{disconnected tracing})" here. What do > you think? I do think we should have that reference there. -- Pedro Alves