Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Frédéric Riss" <frederic.riss@gmail.com>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: gdb-patches@sources.redhat.com
Subject: Re: MI: frozen variable objects
Date: Thu, 16 Nov 2006 21:36:00 -0000	[thread overview]
Message-ID: <1163712982.5060.226.camel@funkylaptop> (raw)
In-Reply-To: <ejibt2$lu6$2@sea.gmane.org>

Le jeudi 16 novembre 2006 à 21:50 +0300, Vladimir Prus a écrit :
> Frederic RISS wrote:
> > The interesting part seems to be the one that hasn't been submited yet
> > about GDB auto-freezing some values due to archtectural requirements.
> > The debugger has architectural knowledge and it shouldn't be necessary
> > to duplicate it in the GUI.
> [...]
> Since GUI typically rely to -var-update to read and report which values have
> changed, it's best to change -var-update not to implicitly read
> read-sensitive values. Doing this in GUI requires that GUI never
> issues -var-update for a variable object that contains read-sensitive
> children. That would be quite a drastic change in GUI architecture.
> 
> With frozen variable object as implemented in the patch, GUI need only
> localized straight-forward changes.

First, note that I don't argue against adding support to the varobjs for
``frozen values'', even if that's what my mail sounded like :-). 

I gathered from your first mail that the ultimate goal is to add support
in GDB for 'read-sensitive' data. That support shouldn't be limited to
MI varobjs as Daniel pointed out. To get this support for the CLI,
you'll certainly need low-level changes in GDB's value handling.

If the above is right, then the low-level changes will prevent the
varobj layer from fetching the data, and you kinda get the result you
wanted. You'd just need to make sure that the data gets fetched when
requested explicitly and to report the not-fetched-because-sensitive
varobj state. 

Of course that would only work for read-sensitive data and wouldn't
allow the GUI to freeze others values. If you believe this additional
functionality would be useful to frontends, I think your opinion as a
KDevelop developer is worth listening to :-)

Fred.



  reply	other threads:[~2006-11-16 21:36 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 [this message]
2006-11-17  6:17         ` Vladimir Prus
2006-11-17  8:54           ` Frederic RISS
2006-11-16 18:47   ` Vladimir Prus
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=1163712982.5060.226.camel@funkylaptop \
    --to=frederic.riss@gmail.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=ghost@cs.msu.su \
    /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