Re: MI: frozen variable objects

[Frederic RISS <frederic dot riss at st dot com>]

On Thu, 2006-11-16 at 10:55 -0500, Daniel Jacobowitz wrote:
> 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).

[Not directly related to the varobj-freezing topic: I think that GUIs
had a better time doing exactly what you say rather than doing it in a
"I know better than the debugger"-way. I've already been quite irritated
with Eclipse doing endianness swapping by itself in its memory view.]

> > The interesting part seems to be the one that hasn't been submited yet
> > about GDB auto-freezing some values due to archtectural requirements.
> > The debugger has architectural knowledge and it shouldn't be necessary
> > to duplicate it in the GUI.
> 
> Exactly.  My original sketch for this stuff had an XML file that we
> passed from the target directly to the GUI, but that duplicates a
> certain amount of work between GDB and the GUI, and between GUIs.
> 
> > I agree with your general point though. Maybe the functionality
> > shouldn't be in the debugger, but the information should be available to
> > the GUI... through varobj properties maybe? Of course this means that
> > the GUIs have to known about and respect this information.
> 
> And what about people who actually use the command line GDB?  That was
> the argument that tipped the scales for me in favor of this approach.
> It allows the varobj mechanism to be consistent with what we want the
> GDB CLI to offer to the user.

Of course things should be consistent between frontends... but I think
that could be argument _against_ the varobj-freezing. If we take a look
at your example:

> struct regs
> {
>   int InterruptStatus;
>   int Config;
>   int ClockVal;
> } *regs;
> 
> Maybe Config is a static register, ClockVal is a continually updating
> read-only timer, and InterruptStatus is a read-sensitive value where
> reading acknowledges any reported interrupt (this is not uncommon). If
> the user does "print/x *regs", and GDB can determine that yes, regs is
> really pointing to some hardware registers that GDB knows about, it
> would be awesome for GDB to say:
> 
> $1 = { InterruptStatus = <read-sensitive>, Config = 0x8000,
>        ClockVal = 0x1212 }

The CLI doesn't use varobjs to display values. Vladimir's change
wouldn't directly help here. Maybe the framework for doing exactly that
should land first and then the UI. I suspect that if CLI is modified to
generate an output like you describe, MI would get something similar as
a side-effect, wouldn't it? 

Fred.