From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30113 invoked by alias); 16 Nov 2006 15:55:20 -0000 Received: (qmail 30104 invoked by uid 22791); 16 Nov 2006 15:55:19 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 16 Nov 2006 15:55:13 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GkjZw-0003DV-37; Thu, 16 Nov 2006 10:55:04 -0500 Date: Thu, 16 Nov 2006 15:55:00 -0000 From: Daniel Jacobowitz To: Frederic RISS Cc: Greg Watson , Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: MI: frozen variable objects Message-ID: <20061116155504.GA11539@nevyn.them.org> Mail-Followup-To: Frederic RISS , Greg Watson , Vladimir Prus , gdb-patches@sources.redhat.com References: <200611161547.46997.vladimir@codesourcery.com> <1163690698.3219.199.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1163690698.3219.199.camel@localhost.localdomain> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00140.txt.bz2 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 = , 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