From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13935 invoked by alias); 17 Nov 2006 15:21:38 -0000 Received: (qmail 13924 invoked by uid 22791); 17 Nov 2006 15:21:37 -0000 X-Spam-Check-By: sourceware.org Received: from elasmtp-dupuy.atl.sa.earthlink.net (HELO elasmtp-dupuy.atl.sa.earthlink.net) (209.86.89.62) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Nov 2006 15:21:32 +0000 Received: from [68.166.114.35] (helo=[IPv6:::1]) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gl5Ww-0001q9-D5; Fri, 17 Nov 2006 10:21:27 -0500 In-Reply-To: <20061116155504.GA11539@nevyn.them.org> References: <200611161547.46997.vladimir@codesourcery.com> <1163690698.3219.199.camel@localhost.localdomain> <20061116155504.GA11539@nevyn.them.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D296C56-6885-454D-9469-6F18F67DE6B6@computer.org> Cc: Frederic RISS , Vladimir Prus , gdb-patches@sources.redhat.com Content-Transfer-Encoding: 7bit From: Greg Watson Subject: Re: MI: frozen variable objects Date: Fri, 17 Nov 2006 15:21:00 -0000 To: Daniel Jacobowitz X-Mailer: Apple Mail (2.752.2) X-ELNK-Trace: b18dadd04c208faa1aa676d7e74259b7b3291a7d08dfec7920be3772677338154ba37e2d8005a0c3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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/msg00170.txt.bz2 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