Re: [PATCH] Print trace state variables

Joel Brobecker
2010-12-11T05:55:26Z

> 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).

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?

One question that worries me: What if the user tries to assign to
an internal variable which collides with one of the tracepoint
variables, and then tries to print it? I think he'll see the tracepoint
variable value, which will make it look like as if his assignment
had no effect.

> 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.

--
Joel