From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13271 invoked by alias); 12 Apr 2002 00:08:45 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 13264 invoked from network); 12 Apr 2002 00:08:44 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 12 Apr 2002 00:08:44 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 4FC033CD1; Thu, 11 Apr 2002 20:08:49 -0400 (EDT) Message-ID: <3CB62591.8010207@cygnus.com> Date: Thu, 11 Apr 2002 17:08:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.9) Gecko/20020328 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner Cc: gdb@sources.redhat.com Subject: Re: [rfc] ``pc'' -> resume_addr? References: <3CB5F437.30607@cygnus.com> <1020411205831.ZM3555@localhost.localdomain> <3CB60B21.10407@cygnus.com> <3CB61DCD.90603@cygnus.com> <1020411234810.ZM4422@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00193.txt.bz2 > On Apr 11, 7:35pm, Andrew Cagney wrote: > >> Subject: Re: [rfc] ``pc'' -> resume_addr? > >> > frame->pc ==> frame->resume_addr >> > >> > This, I think, should change. I'm 99% sure that this isn't the >> > hardware PC but rather the continue address for the frame (but >> > notice I'm not 100% sure thanks to its poor definition). > >> >> Hmm, there is another approach here. As with frame_base() from my >> previous post, a more dynamic: >> >> frame_resume_addr (frame) >> >> that would let the ISA code compute it on demand using the frame's >> register information - in theory frame->pc could be removed. > > > Sure. > > But what are the advantages of doing it this way? Is there a reason > it needs to be this dynamic? If it's computation is significant (target overhead), and its value isn't needed immediatly, then yes. Consider the situtation JimI described. An inferior function call invalidates the frame cache. To re-find the selected frame after that call, GDB needs to re-create each frame until it locates the selected one. During the search, the only thing that absolutly needs to be computed for each frame, is frame->addr. enjoy, Andrew