This is the mail archive of the
mailing list for the GDB project.
Re: [rfc] ``pc'' -> resume_addr?
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'.
> 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;
> 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 -
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:
> *(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.