From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29773 invoked by alias); 22 Nov 2012 18:33:00 -0000 Received: (qmail 29760 invoked by uid 22791); 22 Nov 2012 18:32:59 -0000 X-SWARE-Spam-Status: No, hits=-7.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Nov 2012 18:32:52 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAMIWmTs019493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Nov 2012 13:32:48 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qAMIWjKV024214; Thu, 22 Nov 2012 13:32:45 -0500 Message-ID: <50AE6FCC.4020205@redhat.com> Date: Thu, 22 Nov 2012 18:33:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Yao Qi CC: Marc Khouzam , "'dje@google.com'" , "'gdb-patches@sourceware.org'" Subject: Re: [PATCH 2/2] new tracepoint downloaded MI notification. References: <1348793347-12556-1-git-send-email-yao@codesourcery.com> <1348793347-12556-3-git-send-email-yao@codesourcery.com> <20604.20455.105300.495734@ruffy2.mtv.corp.google.com> <509167D4.20007@redhat.com> <5091C0B0.5000508@codesourcery.com> In-Reply-To: <5091C0B0.5000508@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2012-11/txt/msg00603.txt.bz2 Marc Khouzam wrote: > In older GDB versions, when creating a tracepoint during a trace run, > that tracepoint would not be pushed to the target until the next > trace run. The idea is that a frontend could indicate which tracespoints > were active on the target and which were not. > > Now that GDB pushes new tracepoints to the target immediately, that > use-case may not apply, but I wonder if there are other situations > where some tracepoints will be on the target and other will not? What about the case of connecting to a target that is tracing, after disconnected tracing? Do we already tell the frontend somehow which tracepoints are active on the target? Should tracepoints have an "installed on target" field? Yao Qi wrote: > On 11/01/2012 03:09 AM, Marc Khouzam wrote: >> Now that GDB pushes new tracepoints to the target immediately, that >> use-case may not apply, but I wonder if there are other situations >> where some tracepoints will be on the target and other will not? > > Yes, the pending tracepoints won't be downloaded after tracing is started until they are resolved. The notification is required for this case. Ok. If the answer to my question above is yes, it might be this notification ends up unnecessary in favor of a generic =breakpoint-modified. -- Pedro Alves