Re: MI: frozen variable objects

[Greg Watson <g.watson@computer.org>]

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