From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7070 invoked by alias); 2 May 2006 12:50:21 -0000 Received: (qmail 7053 invoked by uid 22791); 2 May 2006 12:50:20 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 02 May 2006 12:50:18 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1FauKP-0003S9-4d for gdb@sources.redhat.com; Tue, 02 May 2006 16:50:15 +0400 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1FauJi-0003Dh-Ih; Tue, 02 May 2006 16:49:27 +0400 From: Vladimir Prus To: Jim Ingham Subject: Re: -var-update and address changes Date: Tue, 02 May 2006 12:50:00 -0000 User-Agent: KMail/1.7.2 Cc: Daniel Jacobowitz , gdb@sources.redhat.com References: <20060414131549.GC12955@nevyn.them.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200605021649.22475.ghost@cs.msu.su> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00007.txt.bz2 On Friday 14 April 2006 23:49, Jim Ingham wrote: > Note as an aside, that we had to add another varobj type which is > evaluated in the selected frame, whatever that happens to be. That > was useful for a general "variable inspector" window. People wanted > to put some expression there, and have it re-evaluated in the topmost > frame whenever they stopped. So we added that functionality. But > that is clearly distinct from what the "*" varobj type is supposed to > mean. Hi Jim, is this "variable inspector" the same thing that's called "watches" in other IDEs? Well, I really wish that gdb did support variable objects that are reevaluated in the current frame. As it stands now, I have to re-create variable objects on each step. Alternatively, it might be good if gdb provided some way to identify specific scope. Then, "watches" can be bound to that scope and be automatically disabled when out of scope. In other words, suppose that while inside some function I'm interested in value of "i + 10". Then, there are two choices: - Somehow record the scope where I'm interested in that expression, and show expression as disabled elsewhere. - Try to recompute the expression on each stop. While the second approach at least guarantees that the expression will be re-evaluated each time I enter the "interesting" scope, it also involves a bit of extra work for re-evaluating it in other "uninteresting" scopes. - Volodya