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



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


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