This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: MI: frozen variable objects
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