Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Stan Shebs <stan@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Print trace state variables
Date: Sat, 11 Dec 2010 05:55:00 -0000	[thread overview]
Message-ID: <20101211055510.GE2596@adacore.com> (raw)
In-Reply-To: <4D015A4A.7040500@codesourcery.com>

> 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


  parent reply	other threads:[~2010-12-11  5:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-09 22:38 Stan Shebs
2010-12-10 11:27 ` Joel Brobecker
2010-12-10 14:04   ` Stan Shebs
2010-12-10 16:35   ` Marc Khouzam
2010-12-10 20:00     ` Tom Tromey
2010-12-11  5:28       ` Joel Brobecker
2010-12-11  5:55 ` Joel Brobecker [this message]
2010-12-13  5:56   ` Stan Shebs
2010-12-13 13:00   ` Pedro Alves
2010-12-14 16:13   ` Tom Tromey
2010-12-13 12:31 ` Hui Zhu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101211055510.GE2596@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=stan@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox