Re: [PATCH] Print trace state variables

Stan Shebs
2010-12-13T05:56:36Z

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