From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29271 invoked by alias); 15 Dec 2009 19:04:59 -0000 Received: (qmail 29136 invoked by uid 22791); 15 Dec 2009 19:04:58 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS 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; Tue, 15 Dec 2009 19:04:54 +0000 Received: (qmail 5945 invoked from network); 15 Dec 2009 19:04:53 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Dec 2009 19:04:53 -0000 Message-ID: <4B27DDCF.9050106@codesourcery.com> Date: Tue, 15 Dec 2009 19:04:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Eli Zaretskii CC: Stan Shebs , gdb-patches@sourceware.org Subject: Re: [PATCH] Trace state variables References: <4B279456.1010508@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 2009-12/txt/msg00193.txt.bz2 Eli Zaretskii wrote: >> Date: Tue, 15 Dec 2009 05:51:18 -0800 >> From: Stan Shebs >> >> One of our tracepoint enhancements is to add the notion of a "trace >> state variable", which is a GDB-defined piece of data managed by the >> tracepoint agent on the target; one could think of it as a target-side >> convenience variable. >> > > Thanks. > > >> In keeping with their convenience-like nature, they are introduced >> with a dollar sign >> > > But the code seems to allow with or without the $, right? Like here: > > >> + /* Be relaxed about the special character. */ >> + if (*name == '$') >> + ++name; >> I was thinking to let internal API work or without, for flexibility, but this routine is only called in one place, so I'll just make it consistently require. > > A few comments: > > >> + /* Make sure the tsv number is in range. */ >> + if (num < 0 || num > 0xffff) >> + error (_("GDB bug: ax-general.c (ax_tsv): variable number out of range")); >> > > Should this be internal_error instead? > Yep. > >> + warning (_("No trace variable named \"$%s\", not deleting"), name); >> > > The "not deleting" part seems unnecessary. > I suppose so. I always like to have warnings say what GDB is going to do with the situation, even if it seems somewhat obvious to us, because it may not be as obvious to the user (after all, they're getting a warning because things are not going as expected). >> + printf_filtered (" "); >> + else >> + /* It is not meaningful to ask about the value. */ >> + printf_filtered (" "); >> > > No translations for these two? > > Oversight. >> + A second @code{tvariable} >> + command with the same name assigns a new value to the variable. >> > > I don't understand this sentence: what ``second command''? what ``new > value''? Did you mean to say that each tvariable command overwrites > the previous value by a new one? > Yeah, I'll improve the phrasing. >> + List all the trace state variables along with their initial values. >> > ^^^^^^^^^^^^^^^^^^^^ > But in reality the current values are displayed as well, right? > Yep. >> + @item QTDV:@var{n}:@var{value} >> > > Don't we have index entries for all the packets we support? > Excellent idea, I should do that. :-) >> + @item V@var{value} >> + The value of the variable is @var{value}. This will be the current >> + value of the variable if the user is examining a running target, or a >> + saved value if the variable was collected in the trace frame that the >> + user is looking at. Note that multiple requests may result in different >> + reply values, such as for variables like @code{$trace_timestamp} that are >> + computed by the target program. >> > > What is this $trace_timestamp variable mentioned in the last sentence? > I thought trace state variables need to be declared before they can be > used, so how come we evidently have special internally generated > variables with magic features? What am I missing here? > > Oops, a communique from the future. :-) An upcoming patch will add the capability for a target to define its own builtin variables, whose definitions are uploaded upon connection. Stan