From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6340 invoked by alias); 14 Apr 2006 20:03:31 -0000 Received: (qmail 6329 invoked by uid 22791); 14 Apr 2006 20:03:30 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Apr 2006 20:03:29 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k3EK2lTl019763; Fri, 14 Apr 2006 13:02:47 -0700 (PDT) Received: from [17.201.22.240] (unknown [17.201.22.240]) by relay5.apple.com (Apple SCV relay) with ESMTP id C11E2324002; Fri, 14 Apr 2006 13:02:47 -0700 (PDT) In-Reply-To: <20060414195312.GB22562@nevyn.them.org> References: <1A00C3C1-BDF5-489E-A36A-A1E5C20E102A@apple.com> <20060414131549.GC12955@nevyn.them.org> <20060414195312.GB22562@nevyn.them.org> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Vladimir Prus , gdb@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: -var-update and address changes Date: Fri, 14 Apr 2006 20:27:00 -0000 To: Daniel Jacobowitz X-Mailer: Apple Mail (2.749.3) 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/msg00210.txt.bz2 On Apr 14, 2006, at 12:53 PM, Daniel Jacobowitz wrote: > 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" :-) Yeah, every time I have to fix this code, I have to figure out the difference between "current frame" and "selected frame". Once I've thought about it a bit, I'm convinced that it's clear. But then I forget it almost immediately... > >> 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. If you have a disassembly view showing, and you are clicking around on the stack, Xcode fetches enough code to fill the disassembly window around the pc of the frame you've selected on the stack. Having the pc returned with the stack frame eliminates one round trip. People tend to nervously click around on the stack for no apparent reason while they are thinking about the problem they are working on. So this needs to be somewhat quick, though this one round trip is probably negligible. OTOH the fewer things you have to do by "send a request, wait for the reply, do the next request" the easier it is to program on the client side. I wouldn't lean too hard on this one way or another. Jim