Re: [RFA] block_innermost_frame tweak

Andrew Cagney
2002-06-21T22:55:40Z

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