From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9348 invoked by alias); 17 Nov 2006 15:15:41 -0000 Received: (qmail 9339 invoked by uid 22791); 17 Nov 2006 15:15:40 -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; Fri, 17 Nov 2006 15:15:34 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Gl5R1-0008DZ-3M; Fri, 17 Nov 2006 10:15:19 -0500 Date: Fri, 17 Nov 2006 15:15:00 -0000 From: Daniel Jacobowitz To: Greg Watson Cc: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: MI: frozen variable objects Message-ID: <20061117151519.GA31319@nevyn.them.org> Mail-Followup-To: Greg Watson , Vladimir Prus , gdb-patches@sources.redhat.com References: <200611161547.46997.vladimir@codesourcery.com> <37D0E16F-2E33-47F4-9121-FC9125174F20@computer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37D0E16F-2E33-47F4-9121-FC9125174F20@computer.org> 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/msg00168.txt.bz2 On Fri, Nov 17, 2006 at 08:09:12AM -0700, Greg Watson wrote: > I agree that gdb should be where the actual check for value change is > done. Maybe I'm missing something here, but I still don't understand > the reason for requiring frozen values to be implemented in gdb. Is > it just to allow your GUI to issue a single '-var-update *' each time > the debugger suspends? In other words, you're implementing additional > functionality in gdb to support this operation for the GUI. That's one reason. The other is that -var-list-children --all-values shouldn't read it either. Yes, a GUI could avoid that operation too; but offering them when they're dangerous to use seems very unwise. Isn't all of varobj an additional functionality to support GUI operations? > In our > GUI (Eclipse-based, but not CDT), we have a class representing each > variable, and a variable manager that is responsible for deciding > which variables to check for updates. If a particular variable is not > visible in the UI, or does not have some other condition on it, then > we simple do not issue a -var-update command for that variable at > all. It should be trivial to provide a 'read-sensitive' flag in the > variable attributes that is read by the GUI when the variable is > created, and it would never issue a -var-update for that variable. True. If your GUI doesn't use any of the problematic commands, then there's no bug - seems like a trivial reduction to me. > Incidentally, we moved away from the '-var-update *' approach because > it causes gdb 6.5 to crash in certain situations under Linux. I hope you'll forgive me for saying that that's infuriating behavior. The CDT developers seem to do it too. I don't believe you've reported this bug; therefore it will never be fixed, and folklore will propogate that -var-update * is unusable. Please report bugs! I realize our bug tracker doesn't have the timeliest response. With only volunteers to work with, we do what we can, but I try to make sure that the important ones get fixed. And the very best thing you can do with a bug report is to include details and a testcase. -- Daniel Jacobowitz CodeSourcery