Re: [RFA] block_innermost_frame tweak

[Andrew Cagney <ac131313@cygnus.com>]

> 
> 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