This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] block_innermost_frame tweak


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.
Yes, and in each of the above, the PC designates the address of an instruction that, hopefully, the target would/could resume execution from.


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.
Oops, I guess we're back to frame_address_in_block() then?

Andrew



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]