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

[Michael Snyder <msnyder at redhat dot com>]

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