From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2747 invoked by alias); 14 Apr 2006 19:53:22 -0000 Received: (qmail 2739 invoked by uid 22791); 14 Apr 2006 19:53:21 -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, 14 Apr 2006 19:53:19 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FUULw-0005sg-SG; Fri, 14 Apr 2006 15:53:12 -0400 Date: Fri, 14 Apr 2006 20:09:00 -0000 From: Daniel Jacobowitz To: Jim Ingham Cc: Vladimir Prus , gdb@sources.redhat.com Subject: Re: -var-update and address changes Message-ID: <20060414195312.GB22562@nevyn.them.org> Mail-Followup-To: Jim Ingham , Vladimir Prus , gdb@sources.redhat.com References: <1A00C3C1-BDF5-489E-A36A-A1E5C20E102A@apple.com> <20060414131549.GC12955@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes 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-04/txt/msg00209.txt.bz2 On Fri, Apr 14, 2006 at 12:49:05PM -0700, 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. Well, I interpreted it the other way around, so I'll dispute your "clearly" :-) > The fp part is just used as part of the frame fingerprint. The pc is > used for other purposes of course (for instance if the disassembly > window is open), but the fp part is just used to check whether the > frame needs to be refreshed. I have no problem with it being opaque. It's the PC of the frame, not the current PC; I'm not sure why you'd want to use it. In any case, you can always fetch it for the frame, or report it separately. So, let's plan on using frame IDs in MI, and defining them opaquely. I'd even go so far as to make them strings rather than numbers. -- Daniel Jacobowitz CodeSourcery