Re: infrun.c:restore_selected_frame???

[Andrew Cagney <ac131313 at cygnus dot com>]

I wrote:

> Hmm, to more robustly identify a frame, should we save both the frame->frame and frame->pc (or containing function)?  This is separate / independant - I've always wondered if frame->frame was sufficient.
> 
> We do this in Project Builder, but there we do it because a GUI has to present the WHOLE stack frame every time you step, which is slow, so we optimize this by sending frame+pc duples to PB using a special purpose command that just gets these and doesn't reconstruct the whole stack.
> 
> Don't know if you need this in gdb though.  When did you think this might be a problem?

Jim wrote:

>>   When did you think this might be a problem?

I think I've I figured it out.

To safely identify a frame, I think the ->addr/base and the ->func/pc 
are needed.  The dwarf2cfi stuff drops the hint as to why.

Consider a function that doesn't create a frame.  A call through that 
function can result in two stack frames having the same ->frame value. 
They can only be differentiated by using the ->pc.

I think, the correct way to identify a frame is to save:

	->frame
		as before, a constant value that doesn't
		change through out the lifetime of the function
	->func
		i.e. function_containing(->pc)
		(It turns out that, whenever a frame is created
		this is computed anyway!)

I think ->func and not ->pc is needed so that it is possible to identify 
a frame at different points in its execution (eg stepping through the 
inner-most frame).

--

dwarf2cfi doesn't allow for a (mutually) recursive frameless function 
(where both ->frame and ->func would be identical).


enjoy,
Andrew