Re: [RFA] block_innermost_frame tweak

Andrew Cagney
2002-06-21T20:24:09Z

> Andrew Cagney <ac131313@cygnus.com> writes:
>
>> Is there a better name? As you note, it isn't a valid PC (it may not
>> even point into an instruction!). Further, it is isn't the address of
>> the instruction ``calling'' the ``frame''. Last time this came up
>> address_in_block() was used - frame_address_in_block()?
>
>
> I don't disagree with your objections (raised in a previous
> discussion) that `frame->pc - 1' isn't a proper PC. It may never have
> been the value of the PC register (if indeed the architecture has a
> register named `PC'); it doesn't even necessarily point to an
> instruction.
>
> That said, I feel that replacing "PC" with just "address" actually
> makes matters worse, not better. It's very helpful to see at a glance
> that a particular CORE_ADDR value is a pointer into the instruction
> stream. The exact semantics of the value --- is this the return
> address or the address of the call? do we need to apply
> DECR_PC_AFTER_BREAK? and so on --- is something that one uncovers
> when one researches the value more carefully, as with anything else.

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.

> 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()?

enjoy,
Andrew