Re: MI: frozen variable objects

[Daniel Jacobowitz <drow at false dot org>]

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

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.

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.

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

That's not immediately clear what I mean.  Here's a sample.  This is
mostly pipe dream, I don't think we're going to implement it right now. 
But suppose you have a type:

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 }

I haven't thought too much about the UI here, so don't take it too
seriously.  The key is to warn the user before they mess with the
state of their board doing something that seems like it ought to
be harmless.

-- 
Daniel Jacobowitz
CodeSourcery