From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9671 invoked by alias); 16 Nov 2006 18:47:01 -0000 Received: (qmail 9656 invoked by uid 22791); 16 Nov 2006 18:47:00 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 16 Nov 2006 18:46:46 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GkmFK-0001h0-6m for gdb-patches@sources.redhat.com; Thu, 16 Nov 2006 19:45:58 +0100 Received: from 73-198.umostel.ru ([82.179.73.198]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Nov 2006 19:45:58 +0100 Received: from ghost by 73-198.umostel.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Nov 2006 19:45:58 +0100 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: MI: frozen variable objects Date: Thu, 16 Nov 2006 18:47:00 -0000 Message-ID: References: <200611161547.46997.vladimir@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.2 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/msg00144.txt.bz2 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. - Volodya