Re: [rfc] ``pc'' -> resume_addr?

[Andrew Cagney <ac131313 at cygnus dot com>]

> On Apr 11,  7:35pm, Andrew Cagney wrote:
> 
>> Subject: Re: [rfc] ``pc'' -> resume_addr?
> 
>> > frame->pc    ==> frame->resume_addr
>> > 
>> > This, I think, should change.  I'm 99% sure that this isn't the
>> > hardware PC but rather the continue address for the frame (but
>> > notice I'm not 100% sure thanks to its poor definition).
> 
>> 
>> Hmm, there is another approach here.  As with frame_base() from my 
>> previous post, a more dynamic:
>> 
>> frame_resume_addr (frame)
>> 
>> that would let the ISA code compute it on demand using the frame's 
>> register information - in theory frame->pc could be removed.
> 
> 
> Sure.
> 
> But what are the advantages of doing it this way?  Is there a reason
> it needs to be this dynamic?

If it's computation is significant (target overhead), and its value 
isn't needed immediatly, then yes.

Consider the situtation JimI described.  An inferior function call 
invalidates the frame cache.  To re-find the selected frame after that 
call, GDB needs to re-create each frame until it locates the selected 
one.  During the search, the only thing that absolutly needs to be 
computed for each frame, is frame->addr.

enjoy,
Andrew