From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23264 invoked by alias); 12 Apr 2002 00:34:40 -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 23249 invoked from network); 12 Apr 2002 00:34:38 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 12 Apr 2002 00:34:38 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id RAA22661; Thu, 11 Apr 2002 17:34:36 -0700 (PDT) Message-ID: <3CB628D0.8DC57F22@redhat.com> Date: Thu, 11 Apr 2002 17:34:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Andrew Cagney CC: Kevin Buettner , gdb@sources.redhat.com Subject: Re: [rfc] ``pc'' -> resume_addr? References: <3CB5F437.30607@cygnus.com> <1020411205831.ZM3555@localhost.localdomain> <3CB60B21.10407@cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00196.txt.bz2 Andrew Cagney wrote: > > > On Apr 11, 4:38pm, Andrew Cagney wrote: > > > > > >> GDB, in a number of places, refers to the ``pc'' - PC_REGNUM, frame->pc, > >> read_pc(), write_pc(), ... > >> > >> 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. When are they not the same? > 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. Yeah -- but this is done almost immediately after the target stops. Past that point, the hardware pc _is_ equal to the address at which execution will resume. Before that point, we haven't really built or used very many of these objects called 'pc' or 'something->pc'. Have we? > 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; Uggh. Where does THAT code come from? ;-) > >> With this in mind, I'd like to propose a GDBspeak ``resume_addr''. It > >> is the address of the first instruction that will be executed when the > >> target resumes. > > > > > > So, if I understand you correctly, you're suggesting the following > > renaming: > > > > PC_REGNUM ==> RESUME_ADDR_REGNUM > > This wouldn't change. If the hardware has a ``PC'' like register then > likely the maintainer will retain ``PC_REGNUM'' / $pc as an alias for it. > > > 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). OK, but in that context, it's supposed to be understood that the data structure "frame" contains values for the registers in that frame's context -- not the actual hardware registers. They're all saved values -- not just the pc. > > read_pc() ==> read_resume_addr() > > This one is harder. Perhaphs it can be eliminated. > > > 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 can see that ... > Remember, when making an inferior function call, GDB does not set the > PC. Rather it sets the resume/continue address using the debug info. > For instance, on the sparc, it sets: > > [PC] = resume_addr; > [NPC] = resume_addr + 4; > > This behavour is very different to what the user is trying to achieve if > they enter: > > (gdb) jump *foo *bar > > On a sparc, that would execute: > > *foo > *bar > *(bar + 4) > *(bar + 8) Whoa, you lost me. The "jump" command only accepts one argument. What does "jump *foo *bar" mean? > > Perhaps I've just gotten fond of ``pc'', but I don't really like any > > of these. > > If someone uses PC in a typical e-mail, we'll know what they mean. > However, if someone uses PC when refering to GDB's internals, I don't > know that we'll be as sure. > > enjoy, > Andrew