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