From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24533 invoked by alias); 17 Apr 2006 05:54:30 -0000 Received: (qmail 24521 invoked by uid 22791); 17 Apr 2006 05:54:29 -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; Mon, 17 Apr 2006 05:54:27 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1FVMgn-0008W1-Gg for gdb@sources.redhat.com; Mon, 17 Apr 2006 09:54:22 +0400 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1FVMgS-0008Rd-Rv; Mon, 17 Apr 2006 09:54:00 +0400 From: Vladimir Prus To: Daniel Jacobowitz Subject: Re: -var-update and address changes Date: Mon, 17 Apr 2006 06:18:00 -0000 User-Agent: KMail/1.7.2 Cc: Jim Ingham , gdb@sources.redhat.com References: <20060414200920.GA23018@nevyn.them.org> In-Reply-To: <20060414200920.GA23018@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604170953.57667.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-04/txt/msg00223.txt.bz2 On Saturday 15 April 2006 00:09, Daniel Jacobowitz wrote: > On Fri, Apr 14, 2006 at 01:04:22PM -0700, Jim Ingham wrote: > > 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. > > Let me rephrase. > > This is the PC associated with the frame, right now. It's not the PC > in the frame ID at all. That PC is the start of the function > containing the frame. And that PC is of some use too. I some distant future, I want to make KDevelop remember the state of variables tree for a specific frame. Say, you've entered function 'foo' and switched display format for variable 'mask' from 'natural' to 'binary'. You probably want binary format to be used whenever you enter 'foo' next time. Using frame PC is one way to capture the current frame. It's not ideal, since frame address can change on recompilation, but on the other hand, the worst thing that will happen is that you'll use wrong format for a variable, which is not big problems. So, I think frame PC is useful on it's own. - Volodya