Re: [PATCH] Print trace state variables

[Stan Shebs <stan@codesourcery.com>]

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<stan@codesourcery.com>
>>
>>      * 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