From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13360 invoked by alias); 15 Nov 2011 17:02:18 -0000 Received: (qmail 13350 invoked by uid 22791); 15 Nov 2011 17:02:17 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Nov 2011 17:01:38 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LUP00L00OFZG300@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Tue, 15 Nov 2011 19:00:44 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.124.184.15]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LUP00JDYOL6YGI0@a-mtaout22.012.net.il>; Tue, 15 Nov 2011 19:00:43 +0200 (IST) Date: Tue, 15 Nov 2011 17:02:00 -0000 From: Eli Zaretskii Subject: Re: [patch 5/5] Document In-reply-to: <4EC28062.9090506@mentor.com> To: luis_gustavo@mentor.com Cc: yao@codesourcery.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83ehx9e305.fsf@gnu.org> References: <4EC20E2E.6010402@codesourcery.com> <4EC21DCF.1070003@codesourcery.com> <4EC27821.10806@mentor.com> <4EC27DAE.9040401@codesourcery.com> <4EC28062.9090506@mentor.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/msg00390.txt.bz2 > Date: Tue, 15 Nov 2011 13:08:18 -0200 > From: Luis Machado > CC: gdb-patches@sourceware.org > > On 11/15/2011 12:56 PM, Yao Qi wrote: > > On 11/15/2011 10:33 PM, Luis Machado wrote: > >>> +to breakpoint, @dfn{pending tracepoint}---tracepoint whose address is > >> to breakpoints, @dfn{pending tracepoint}---tracepoints whose addresses are > >> > >>> +not yet resolved, is supported as well. Pending tracepoint is not > >> not yet resolved are supported as well. Pending tracepoints are not > >> > >>> +downloaded to target and not installed until it is resolved. The > >> downloaded to and installed on the target until they are resolved. The > >> > >>> +resolution of pending tracepoint requires @value{GDBN} support. In > >> resolution of pending tracepoints require @value{GDBN} support. In > >> > > I noticed that `pending breakpoint' is in singular form in document, so > > I choose singular form for `pending tracepoint' as well. I am OK with > > either of them. > > Should be OK as well. This is a minor suggestion. It just sounded a bit > more natural. I agree: plural is better. > >>> +tracepoint still exists but can not be resolved during disconnection. > >> tracepoints still exist but will not be resolved until @value{GDBN} > >> reconnects to it. > > There is a minor difference between yours and mine, IIUC. "will not be > > resolved until GDB reconnects to it" means "pending tracepoints will be > > resolved immediately after GDB reconnects to it", which is not true. We > > don't know when a pending tracepoint can be resolved, but we are sure > > that the pending tracepoint can not be resolved when gdb disconnects. > > What do you think > "will not be resolved until GDB reconnects to it" meant to say that > while GDB is disconnected from the remote target, pending tracepoints > won't be resolved. We can be more explicit about this if the phrasing > isn't clear. > > "during disconnection" made it sound like something happens while GDB is > disconnecting. > > Maybe "tracepoints still exist but cannot be resolved while GDB is > disconnected?" Yes.