From: "Marc Khouzam" <marc.khouzam@ericsson.com>
To: "Daniel Jacobowitz" <drow@false.org>
Cc: <gdb-patches@sources.redhat.com>
Subject: RE: [Patch] Fix for -var-update to use natural format to compare
Date: Tue, 22 Jan 2008 14:43:00 -0000 [thread overview]
Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA04290E42@ecamlmw720.eamcs.ericsson.se> (raw)
In-Reply-To: <20080122035325.GA28748@caradoc.them.org>
> > It modifies the variable object code to always uses the natural format to compare
> > old and new values for the -var-update command (one line change).
> > It also renames the member print_value of varobj to natural_value.
>
> I don't think this is an appropriate change.
>
> -var-update is supposed to tell when the displayed value has changed.
> If the value in the current format hasn't changed, there's no need to
> refetch.
This is assuming the frontend only displays a single value.
In DSF, we (sometimes) display all values at once. Can be nice for the user.
> why do you want to keep track of the value in
> all formats? And if you're actually displaying them all
> simultaneously to the user, why shouldn't they be independent varobjs?
Independent varObjects would work. However every time the program stops
the frontend will need to issue a var-update on five objects instead of one,
and what is worse is that GDB will need to read the memory from the target
five times instead of once. This is less efficient than the frontend
forcing GDB to use natural format (see below.)
You can refer to http://sourceware.org/ml/gdb/2008-01/msg00175.html
where you had agreed with me :-)
One solution is the patch I suggested.
An alternative suggestion that would support both use cases,
was to have an extra flag to var-update.
Something like [--content-changed | --last-display-value-changed]
It would be a separate flag than the --no-values one.
The front-end could then decide which behavior it wants.
Although, and I can understand, adding this new flag did not seem too
popular.
To be honest, I will have to support GDB 6.7 anyway, so I will need to
work around this by myself, no matter what. What I will do is that
every time I issue a var-set-format and an evaluate-expression,
I will follow it by another var-set-format to natural to keep all variable
objects to the natural format. This will force GDB to use the natural
format for its var-update comparison.
I just thought that GDB would want to support frontends that display more
than one format at once.
Thanks
Marc
next prev parent reply other threads:[~2008-01-22 14:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-22 3:25 Marc Khouzam
2008-01-22 3:53 ` Daniel Jacobowitz
2008-01-22 14:43 ` Marc Khouzam [this message]
2008-01-22 15:03 ` Daniel Jacobowitz
2008-01-22 15:12 ` Marc Khouzam
2008-01-22 15:35 ` Vladimir Prus
2008-01-22 16:38 ` Marc Khouzam
2008-01-22 17:50 ` Vladimir Prus
2008-01-22 17:59 ` Daniel Jacobowitz
2008-01-23 0:33 ` Nick Roberts
2008-01-23 14:41 ` Marc Khouzam
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=6D19CA8D71C89C43A057926FE0D4ADAA04290E42@ecamlmw720.eamcs.ericsson.se \
--to=marc.khouzam@ericsson.com \
--cc=drow@false.org \
--cc=gdb-patches@sources.redhat.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