Re: MI: frozen variable objects

[Vladimir Prus <vladimir@codesourcery.com>]

Greg Watson wrote:

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

Suppose you have a variable "all_registers" that is actually a big structure
and a few fields on the bottom are read-sensitive.

Current gdb only allows you to issue -var-update on top-level variable
object, so you either issue it, or don't. If you issue it, gdb will happily
fetch new values for the entire structure, including read-sensitive field.
If you don't issue it, you won't get new values for ordinary fields.

Current gdb is not more fine-grained that this, so presenting all registers
as a structure is just not possible.

> Incidentally, we moved away from the '-var-update *' approach because
> it causes gdb 6.5 to crash in certain situations under Linux.

Can you tell exactly what were those situations?

- Volodya