This is the mail archive of the
mailing list for the GDB project.
Re: [rfc] ``pc'' -> resume_addr?
> 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.
> 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.