From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 541 invoked by alias); 11 Apr 2002 23:42:10 -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 517 invoked from network); 11 Apr 2002 23:42:06 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 11 Apr 2002 23:42:06 -0000 Received: from romulus.sfbay.redhat.com (romulus.sfbay.redhat.com [172.16.27.251]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id QAA18412; Thu, 11 Apr 2002 16:42:04 -0700 (PDT) Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g3BNfwx04407; Thu, 11 Apr 2002 16:41:58 -0700 Date: Thu, 11 Apr 2002 16:42:00 -0000 From: Kevin Buettner Message-Id: <1020411234158.ZM4406@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: [rfc] ``pc'' -> resume_addr?" (Apr 11, 6:16pm) References: <3CB5F437.30607@cygnus.com> <1020411205831.ZM3555@localhost.localdomain> <3CB60B21.10407@cygnus.com> To: Andrew Cagney , Kevin Buettner Subject: Re: [rfc] ``pc'' -> resume_addr? Cc: gdb@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg00190.txt.bz2 On Apr 11, 6:16pm, Andrew Cagney wrote: > >> I think this name choice was unfortunate. It is too easy for a > >> developer to confuse ``pc'' with the hardware ``pc''. > > > > Could you please explain further why you think the name choice was > > unfortunate? > > I think the name ``pc'' brings with it a certain amount of baggage. > When reading a piece of code, it isn't clear if the hardware ``pc'' > (possibly needing adjustment) or the program's resume address is being used. Is there really that much confusion about this though? I think that the length of time during which this confusion exists is mercifully brief. AFAICT, gdb's notion of the pc is adjusted shortly after stopping via a call to bpstat_stop_status() and from then on, the pc value is simply the continuation (or resume) address. Even the "PC" value in the register cache has been adjusted to be the program's resume address at this point. I think it'd be better to carefully document the places in gdb where the pc value hasn't yet been adjusted to be the continuation address. > On an x86, and m68k, for instance, the hardware PC may or may not need > to be adjusted (decr_pc_after_break()) before it becomes a frame->pc. > > Within the frame, the ``pc'' designates ``resume'' address of the > function. Knowing this is important when understanding why some of the > frame code does: > > if (frame->next != NULL) > return frame->pc - 1; > else > return frame->pc; Where does this code occur? I'd like to take a closer look... [...] > > 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). I don't disagree with your characterization of it, but I also don't have a problem with continuing to call it ``pc''. Only the topmost frame will have a value that corresponds to the actual hardware pc (modulo some adjustment perhaps). All of the other frames will have pc values which corresond to return addresses. But this is okay. When considering the execution context provided by a particular frame, ``pc'' does correspond to what the hardware pc would be if that frame were executing. > > read_pc() ==> read_resume_addr() > > This one is harder. Perhaphs it can be eliminated. I think it may prove somewhat difficult to eliminate read_pc(). > > write_pc() ==> write_resume_addr() > > Check the default implementation. It not only modifies PC, but also NPC > and even NNPC. I think this function should be called something like - > set_resume_address()? I agree with this. Kevin