From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24590 invoked by alias); 11 Apr 2002 22:15:58 -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 24582 invoked from network); 11 Apr 2002 22:15:57 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 11 Apr 2002 22:15:57 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id CF5C83CD1; Thu, 11 Apr 2002 18:16:01 -0400 (EDT) Message-ID: <3CB60B21.10407@cygnus.com> Date: Thu, 11 Apr 2002 15:15: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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00185.txt.bz2 > 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. 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; >> 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). > 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()? 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) > 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