From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1466 invoked by alias); 17 Nov 2006 15:09:26 -0000 Received: (qmail 1445 invoked by uid 22791); 17 Nov 2006 15:09:25 -0000 X-Spam-Check-By: sourceware.org Received: from elasmtp-banded.atl.sa.earthlink.net (HELO elasmtp-banded.atl.sa.earthlink.net) (209.86.89.70) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Nov 2006 15:09:16 +0000 Received: from [68.166.114.35] (helo=[IPv6:::1]) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gl5L7-0005f2-6K; Fri, 17 Nov 2006 10:09:13 -0500 In-Reply-To: References: <200611161547.46997.vladimir@codesourcery.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <37D0E16F-2E33-47F4-9121-FC9125174F20@computer.org> Cc: gdb-patches@sources.redhat.com Content-Transfer-Encoding: 7bit From: Greg Watson Subject: Re: MI: frozen variable objects Date: Fri, 17 Nov 2006 15:09:00 -0000 To: Vladimir Prus X-Mailer: Apple Mail (2.752.2) X-ELNK-Trace: b18dadd04c208faa1aa676d7e74259b7b3291a7d08dfec79bb2b64fe554618d693b7aa1f78ca796d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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/msg00167.txt.bz2 On Nov 16, 2006, at 11:45 AM, Vladimir Prus wrote: > 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. > > I think it's not feasible to implement frozen variable objects in GUI > without sacrificing performance. > > Suppose that you have a huge structure containing nothing less than > all > memory mapped registers of a target. That's how we plan to present > target > registers in UI. > > There's a variable object corresponding to the entire structure, > that has > children corresponding to register or register groups. The latter > have more > children. On each step, -var-update is used to find all elements of > this > structure that has changed. The comparison of all values is done by > gdb. > That's a good side of MI -- otherwise, GUI would have to read value > of every > single structure element and compare it itself. It would be slow. > > With read-sensitive values, we don't want gdb to read such values > on each > step. This is done by marking such values as frozen. As result, gdb > will > only read those values on explicit request. The changes in gdb are: > > (1) Reporting that a variable object is frozen. > (2) Not updating frozen variable object automatically > (3) Ability to update non-root variable object > > (1) and (2) are certainly needed -- I see no way around. As for (3), > I can imagine that GUI might notice that a child variable is frozen, > create new root variable object for that child, and update it as > needed. > But still, the child corresponding to read-sensitive field should > be be > updated. And I don't see why creating new root variable is better > than -var-update for a child. > > Non-updating of frozen variable objects is the most complex part of > this > patch, and as I say above, it's absolutely needed. > > Another argument in favour of doing this in GDB is that I've > prototyped GUI > side of things in KDevelop and now working on it in Eclipse, and it > both > cases GUI changes are straight-forward. You just > > - Make UI show some indicator for frozen variables. > - Add "Fetch this value" command that issues -var-update > > Any other approach to handle this from GUI side would me much > harder to > implement. > 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. 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. Incidentally, we moved away from the '-var-update *' approach because it causes gdb 6.5 to crash in certain situations under Linux. Regards, Greg