From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17784 invoked by alias); 17 Nov 2006 15:27:53 -0000 Received: (qmail 17767 invoked by uid 22791); 17 Nov 2006 15:27:52 -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; Fri, 17 Nov 2006 15:27:44 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gl5cg-0003lh-9e for gdb-patches@sources.redhat.com; Fri, 17 Nov 2006 16:27:22 +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 ; Fri, 17 Nov 2006 16:27:22 +0100 Received: from vladimir by 73-198.umostel.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 16:27:22 +0100 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: MI: frozen variable objects Date: Fri, 17 Nov 2006 15:27:00 -0000 Message-ID: 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-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/msg00172.txt.bz2 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. 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. Suppose you have a variable "all_registers" that is actually a big structure and a few fields on the bottom are read-sensitive. Current gdb only allows you to issue -var-update on top-level variable object, so you either issue it, or don't. If you issue it, gdb will happily fetch new values for the entire structure, including read-sensitive field. If you don't issue it, you won't get new values for ordinary fields. Current gdb is not more fine-grained that this, so presenting all registers as a structure is just not possible. > Incidentally, we moved away from the '-var-update *' approach because > it causes gdb 6.5 to crash in certain situations under Linux. Can you tell exactly what were those situations? - Volodya