From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26702 invoked by alias); 13 Dec 2010 05:56:36 -0000 Received: (qmail 26692 invoked by uid 22791); 13 Dec 2010 05:56:35 -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; Mon, 13 Dec 2010 05:56:29 +0000 Received: (qmail 24078 invoked from network); 13 Dec 2010 05:56:27 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 13 Dec 2010 05:56:27 -0000 Message-ID: <4D05B58A.4020405@codesourcery.com> Date: Mon, 13 Dec 2010 05:56:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [PATCH] Print trace state variables References: <4D015A4A.7040500@codesourcery.com> <20101211055510.GE2596@adacore.com> In-Reply-To: <20101211055510.GE2596@adacore.com> 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: 2010-12/txt/msg00173.txt.bz2 On 12/10/10 9:55 PM, Joel Brobecker wrote: >> This has been in CodeSourcery's version for some time, but I set it >> aside for awhile because it seemed a little kludgy to add a >> tracepoint-specific case into general evaluation. > I think a cleaner way of doing this would be to create a new OP_ enum > for tracepoint variables. We'd then add handling for it in > write_dollar_variable, as well as in the expression evaluator. > > One potential issue with that approach is that it might require each > language to also add handling for that operator, but if all languages > are implemented the way Ada is (for operators that do not need to be > handled specifically in Ada, we default to the standard evaluator > (evaluate_subexp_standard or something like this). I originally thought adding an OP was too intrusive for what is kind of a special case, but I suppose it's not really any freakier than some of the other expression types. :-) > Another potential issue to consider is precedence: If the user had > already defined an internal variable called "VAR", and then creates > a tracepoint variable with the same name, which one should we print > when he write "$VAR"? With your proposal, the tracepoint variable > hides the internal variable, right? That's right. My original specification called for the variables to use $-syntax despite the overloading, because it generally fits into user expectation as a variable that is not part of the program, and also there are not a lot of alternatives available in parsing. The manual dictates that the two types of variables cannot share a name, so a followon patch could detect and disallow overloading - although it seems hard to make it user-friendly, since both kinds of variables can appear in scripts that are loaded. >> 2010-12-08 Stan Shebs >> >> * value.c (value_of_internalvar): Add case for trace state >> variables. >> >> * gdb.trace/tsv.exp: Test print command on trace state variables. > No objection to this, though, since it is relatively contained. > Thanks, I put this in. I do hope to re-address this soon, as part of a project to do target-side conditional breakpoints (read: exploit the tracepoint agent outside of tracing), and make trace state variables into target-managed variables in general. Stan