From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11671 invoked by alias); 15 Nov 2011 15:04:53 -0000 Received: (qmail 11654 invoked by uid 22791); 15 Nov 2011 15:04:51 -0000 X-SWARE-Spam-Status: No, hits=-1.4 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; Tue, 15 Nov 2011 15:04:38 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1RQKYw-0006Es-Ad from Luis_Gustavo@mentor.com for gdb-patches@sourceware.org; Tue, 15 Nov 2011 07:04:38 -0800 Received: from NA1-MAIL.mgc.mentorg.com ([147.34.98.181]) by svr-orw-fem-01.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 07:04:35 -0800 Received: from [0.0.0.0] ([172.16.63.104]) by NA1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 07:04:30 -0800 Message-ID: <4EC28062.9090506@mentor.com> Date: Tue, 15 Nov 2011 15:04:00 -0000 From: Luis Machado Reply-To: luis_gustavo@mentor.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [patch 5/5] Document References: <4EC20E2E.6010402@codesourcery.com> <4EC21DCF.1070003@codesourcery.com> <4EC27821.10806@mentor.com> <4EC27DAE.9040401@codesourcery.com> In-Reply-To: <4EC27DAE.9040401@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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/msg00384.txt.bz2 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. >>> +remote target, when @value{GDBN} disconnects from remote stub, pending >> the remote target, when @value{GDBN} disconnects from the remote stub, >> pending >> > Right, we need "the" here. > >>> +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?" Again, these are minor details.