Re: [RFA] block_innermost_frame tweak

[Jim Blandy <jimb at redhat dot com>]

Andrew Cagney <ac131313@cygnus.com> writes:
> Except for a small window in WFI, a ``PC'' refers to the address of
> the instruction that will be executed next.  It is just unfortunate
> that no one has found the time to zap DECR_PC_AFTER_BREAK and hence
> eliminate that small window.  Please don't add to this confusion.

What about all the prologue analyzers?

    /* Return PC of first real instruction.  */

    int
    i386_skip_prologue (int pc)
    {
      unsigned char op;
      int i;

    static CORE_ADDR
    mn10300_analyze_prologue (struct frame_info *fi, CORE_ADDR pc)
    {

What about the line table entries?

    /* Each item represents a line-->pc (or the reverse) mapping.  This is
       somewhat more wasteful of space than one might wish, but since only
       the files which are actually debugged are read in to core, we don't
       waste much space.  */

    struct linetable_entry
      {
        int line;
        CORE_ADDR pc;
      };

I'm all for choosing conventions and sticking to them, but in everyday
speech (well, everyday speech for debugger people), a `pc' is just any
kind of pointer to an instruction.  And it just looks to me like
that's the way GDB uses it, too.

Why is this distinction so urgent to maintain?  I think I've shown
that it has some cost.

> > But if I'm the only one who has this reaction, then I don't mind the
> > renaming.
> > Is there some third terse term that indicates (or could indicate, by
> > establishing a convention) "pointer into the instruction stream that
> > isn't necessarily an instruction address or the value of a register"?
> 
> The reason for suggesting ``block'' was that it hopefully implies a
> code block. frame_address_within_code_block()?

This is getting worse.