Re: MI: frozen variable objects

Greg Watson
2006-11-17T15:09:26Z

On Nov 16, 2006, at 11:45 AM, Vladimir Prus wrote:

> 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.
>

I agree that gdb should be where the actual check for value change is
done. Maybe I'm missing something here, but I still don't understand
the reason for requiring frozen values to be implemented in gdb. Is
it just to allow your GUI to issue a single '-var-update *' each time
the debugger suspends? In other words, you're implementing additional
functionality in gdb to support this operation for the GUI. In our
GUI (Eclipse-based, but not CDT), we have a class representing each
variable, and a variable manager that is responsible for deciding
which variables to check for updates. If a particular variable is not
visible in the UI, or does not have some other condition on it, then
we simple do not issue a -var-update command for that variable at
all. It should be trivial to provide a 'read-sensitive' flag in the
variable attributes that is read by the GUI when the variable is
created, and it would never issue a -var-update for that variable.
Incidentally, we moved away from the '-var-update *' approach because
it causes gdb 6.5 to crash in certain situations under Linux.

Regards,

Greg