This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI: frozen variable objects


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]