Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Vladimir Prus <ghost@cs.msu.su>
To: gdb-patches@sources.redhat.com
Subject: Re: MI: frozen variable objects
Date: Thu, 16 Nov 2006 18:47:00 -0000	[thread overview]
Message-ID: <ejibjq$lu6$1@sea.gmane.org> (raw)
In-Reply-To: <AA29CD66-FC7C-4C4E-B36A-7945B03AC283@computer.org>

Greg Watson wrote:

> I don't really understand the motivation for putting this kind of
> functionality into gdb. Any GUI that is more than just a front-end
> for gdb will most likely have an internal data structure representing
> the value of the variable, and can retain or manage access to the
> value if required. It seems to me that adding functionality like this
> to gdb just adds to bloat when it is really a GUI function anyway.

I think it's not feasible to implement frozen variable objects in GUI
without sacrificing performance.

Suppose that you have a huge structure containing nothing less than all
memory mapped registers of a target. That's how we plan to present target
registers in UI.

There's a variable object corresponding to the entire structure, that has
children corresponding to register or register groups. The latter have more
children. On each step, -var-update is used to find all elements of this
structure that has changed. The comparison of all values is done by gdb.
That's a good side of MI -- otherwise, GUI would have to read value of every
single structure element and compare it itself. It would be slow.

With read-sensitive values, we don't want gdb to read such values on each
step. This is done by marking such values as frozen. As result, gdb will
only read those values on explicit request. The changes in gdb are:

   (1) Reporting that a variable object is frozen.
   (2) Not updating frozen variable object automatically
   (3) Ability to update non-root variable object

(1) and (2) are certainly needed -- I see no way around. As for (3),
I can imagine that GUI might notice that a child variable is frozen,
create new root variable object for that child, and update it as needed.
But still, the child corresponding to read-sensitive field should be be
updated. And I don't see why creating new root variable is better
than -var-update for a child.

Non-updating of frozen variable objects is the most complex part of this
patch, and as I say above, it's absolutely needed.

Another argument in favour of doing this in GDB is that I've prototyped GUI
side of things in KDevelop and now working on it in Eclipse, and it both
cases GUI changes are straight-forward. You just

   - Make UI show some indicator for frozen variables.
   - Add "Fetch this value" command that issues -var-update

Any other approach to handle this from GUI side would me much harder to
implement.

- Volodya



  parent reply	other threads:[~2006-11-16 18:47 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-16 12:48 Vladimir Prus
2006-11-16 13:58 ` Greg Watson
2006-11-16 15:25   ` Frederic RISS
2006-11-16 15:55     ` Daniel Jacobowitz
2006-11-16 16:26       ` Frederic RISS
2006-11-16 16:34         ` Daniel Jacobowitz
2006-11-17 15:21       ` Greg Watson
2006-11-16 18:55     ` Vladimir Prus
2006-11-16 21:36       ` Frédéric Riss
2006-11-17  6:17         ` Vladimir Prus
2006-11-17  8:54           ` Frederic RISS
2006-11-16 18:47   ` Vladimir Prus [this message]
2006-11-17 15:09     ` Greg Watson
2006-11-17 15:15       ` Daniel Jacobowitz
2006-11-17 15:26         ` Greg Watson
2006-11-17 15:33           ` Daniel Jacobowitz
2006-11-17 15:41             ` Greg Watson
2006-11-17 15:45               ` Daniel Jacobowitz
2006-11-17 18:16               ` Daniel Jacobowitz
2006-11-17 15:35         ` Greg Watson
2006-11-17 15:27       ` Vladimir Prus
2006-11-16 21:53 Nick Roberts
2006-11-16 22:00 ` Daniel Jacobowitz
2006-11-16 23:07   ` Nick Roberts
2006-11-17 15:19     ` Daniel Jacobowitz
2006-11-17 20:52       ` Nick Roberts
2006-11-17 21:05         ` Daniel Jacobowitz
2006-11-17 23:12           ` Nick Roberts
2006-11-18 11:00           ` Eli Zaretskii
2006-11-17  6:25 ` Vladimir Prus
2006-11-17 18:14 ` Daniel Jacobowitz
2006-11-18  6:59 Nick Roberts

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='ejibjq$lu6$1@sea.gmane.org' \
    --to=ghost@cs.msu.su \
    --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