Re: MI: frozen variable objects

[Daniel Jacobowitz <drow at false dot org>]

On Fri, Nov 17, 2006 at 08:09:12AM -0700, 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.

That's one reason.  The other is that -var-list-children --all-values
shouldn't read it either.  Yes, a GUI could avoid that operation too;
but offering them when they're dangerous to use seems very unwise.

Isn't all of varobj an additional functionality to support GUI
operations?

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

True.  If your GUI doesn't use any of the problematic commands, then
there's no bug - seems like a trivial reduction to me.

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

I hope you'll forgive me for saying that that's infuriating behavior.
The CDT developers seem to do it too.  I don't believe you've reported
this bug; therefore it will never be fixed, and folklore will
propogate that -var-update * is unusable.

Please report bugs!

I realize our bug tracker doesn't have the timeliest response.  With
only volunteers to work with, we do what we can, but I try to make sure
that the important ones get fixed.  And the very best thing you can do
with a bug report is to include details and a testcase.

-- 
Daniel Jacobowitz
CodeSourcery