From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23348 invoked by alias); 5 May 2011 23:13:57 -0000 Received: (qmail 23338 invoked by uid 22791); 5 May 2011 23:13:56 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 May 2011 23:13:41 +0000 Received: (qmail 458 invoked from network); 5 May 2011 23:13:40 -0000 Received: from unknown (HELO ?192.168.1.2?) (kcy@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 May 2011 23:13:40 -0000 Message-ID: <4DC32F21.9090400@codesourcery.com> Date: Thu, 05 May 2011 23:13:00 -0000 From: Kwok Cheung Yeung User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Eli Zaretskii CC: gdb-patches@sourceware.org Subject: Re: [PATCH] Support for enabling/disabling tracepoints while a trace experiment is running References: <4DC2DDEF.10600@codesourcery.com> <83hb99m14x.fsf@gnu.org> In-Reply-To: <83hb99m14x.fsf@gnu.org> 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: 2011-05/txt/msg00164.txt.bz2 On 05/05/2011 19:51, Eli Zaretskii wrote: >> Date: Thu, 05 May 2011 18:27:11 +0100 >> From: Kwok Cheung Yeung >> >> + If a trace experiment is started with no enabled >> + tracepoints, then a warning will be printed but the experiment will >> + proceed anyway. > > You mean, if the experiment started with no enabled tracepoints, and > the user says "disable", right? Otherwise, why the warning? > Originally, it was an error to try to start an experiment with no enabled tracepoints because the resulting experiment would never do anything. However, with the patch, tracepoints can be re-enabled after the experiment starts, so I downgraded the error to a warning. I suppose we could do away with it altogether, but then a user who inadvertently disabled all tracepoints might sit and wonder why nothing seems to be happening. >> +* New remote packets >> + >> +QTEnable >> + >> + Dynamically enable a tracepoint in a started trace experiment. >> + >> +QTDisable >> + >> + Dynamically disable a tracepoint in a started trace experiment. > > Can't the existing packets do the job? > As far as I can see, there are no packets that allow a tracepoint that is already created on the target to be modified. It might be possible to extend QTDP: to do so, but that would seem to needlessly complicate its definition (which is to create new tracepoints, not modify existing ones). >> Disable tracepoint @var{num}, or all tracepoints if no argument >> -@var{num} is given. A disabled tracepoint will have no effect during >> -the next trace experiment, but it is not forgotten. You can re-enable >> -a disabled tracepoint using the @code{enable tracepoint} command. >> +@var{num} is given. The change is effective immediately. > > Err... that's inaccurate, isn't it? The code patch clearly shows that > sometimes it won't work: > >> + sprintf_vma (addr_buf, location->address); >> + sprintf (rs->buf, "QTEnable:%x:%s", location->owner->number, addr_buf); >> + putpkt (rs->buf); >> + remote_get_noisy_reply (&rs->buf, &rs->buf_size); >> + if (*rs->buf == '\0') >> + error (_("Target does not support enabling tracepoints while a trace run is ongoing.")); >> + if (strcmp (rs->buf, "OK") != 0) >> + error (_("Error on target while enabling tracepoint.")); > It won't work if the target does not have support for it (i.e. the target was not compiled with this patch) or if an unexpected error occurs (in which case all bets are off). Would something like this be better? Disable tracepoint @var{num}, or all tracepoints if no argument @var{num} is given. A disabled tracepoint will have no effect during -the next trace experiment, but it is not forgotten. You can re-enable +a trace experiment, but it is not forgotten. You can re-enable a disabled tracepoint using the @code{enable tracepoint} command. +If the command is issued during a trace experiment and the debug target +has support for disabling tracepoints during a trace experiment, then the +change will be effective immediately. Otherwise, it will be applied to the +next trace experiment. -Enable tracepoint @var{num}, or all tracepoints. The enabled -tracepoints will become effective the next time a trace experiment is -run. +Enable tracepoint @var{num}, or all tracepoints. If this command is +issued during a trace experiment and the debug target supports enabling +tracepoints during a trace experiment, then the enabled tracepoints will +become effective immediately. Otherwise, they will become effective the +next time a trace experiment is run. Kwok