Re: [rfc] ``pc'' -> resume_addr?

[Kevin Buettner <kevinb at redhat dot com>]

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