Re: MI: frozen variable objects

[Greg Watson <g dot watson at computer dot org>]

On Nov 16, 2006, at 8:55 AM, Daniel Jacobowitz wrote:

> On Thu, Nov 16, 2006 at 04:24:58PM +0100, Frederic RISS wrote:
> > On Thu, 2006-11-16 at 06:58 -0700, 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.
>
> Disclaimer: I've already talked with Vladimir about this at length and
> if I remember right he's the one who persuaded me that GDB was the
> right place to do it.  After this I'll let him speak for himself.
>
> Why should the GUI have a separate data structure for the value in a
> manipulatable form?  I suspect that some GUIs only keep it around as a
> string, for display.  Then if the user wants a radix switch, the
> easiest way is to tell GDB (-var-set-format).

I guess this is ok for GUI's that are just a front-end for gdb. The  
trend seems to be to provide the more sophisticated debugger  
functionality in the GUI and use gdb for lower-level debug  
operations, accessing symbols, etc. This is the case for two parallel  
debuggers I know about, and I suspect we'll see it used more for  
multicore architectures. Ultimately I think there will be  
functionality that can only be provided by the GUI. For example,  
comparing values from programs executing on different cores. I guess  
the trade-off here is the work required in the GUI vs. gdb bloat.

> The overall utility of -var-update * is somewhat suspect, I think,
> since it can take so long to run; to make it practical you'd have to
> delete varobjs for things not currently on-screen.  But as long as  
> that
> functionality exists, we figured it would be nice to not break it.

And buggy :-). But I agree. We're moving away from '-var-update *' to  
checking only the variables that are of interest.

> The read-sensitive values that Vladimir alluded to are our ultimate
> goal here and you'll be seeing rather more of them in the next
> few weeks.  Whenever we've suggested to a customer that our Eclipse
> ought to pop up a window that shows all of their target's peripheral
> I/O registers, the response has been jumping-up-and-down enthusiastic.
> But without some solution for this problem we just can't do it.   
> Having
> that window pop open, acknowledge all your pending interrupts, and
> steal one byte from each serial port FIFO, would be a real downer.

Adding a varobj attribute to provide this information would  
definitely be a cool addition.

Regards,

Greg