Re: [patch/rfc] FRAME_FP() -> get_frame_base()

[Andrew Cagney <ac131313 at redhat dot com>]

> I think get_frame_base() is a good choice.  I like get_frame_address()
> too, but if using "base" somehow helps us to remember that this
> address remains constant, then that's a good thing.
I should note that I really don't have a preference.  Depending on the 
time of day, I'll favour get_frame_address() or get_frame_base().

> [...]
>
> > - (I guess) re-vamp the PPC so that get_frame_base() is constant through 
> > out the lifetime of a frame.
>
> Yes, I guess so.  I had to think about this a while though -- the current
> placement of ->frame makes a lot of sense.
Yes, given the PPC ABIs, the current code does make a lot of sense. 
I've looked at changing it before but backed away.

The PPC could easily maintain both pointers.  Have get_frame_XXX() 
return a constant, but locally, use the stack top.

Two technical points, I think, swing things in favour of the change:


- gdb really needs a constant frame address if it is going to correctly 
re-locate a frame after a target resume.

Without this, gdb can't get edge cases right.  Eg, consider a stack like:

	outer()
	middle()
	inner() #1

which is then transformed to:

	outer()
	middle()
	inner() #1
	inner() #2

Unless the frame is constant, gdb would mistake inner()#2 for inner()#1.


- the dummy frame code, for the PPC, needs to do a stack upwind when 
trying to identify a dummy frame.  It should be possible to avoid this.


Andrew