Re: Proposed mod for stack-select-frame MI command

[Elena Zannoni <ezannoni at redhat dot com>]

Mo DeJong writes:
 > On Thu, 01 Aug 2002 19:25:30 -0400
 > Andrew Cagney <ac131313@ges.redhat.com> wrote:
 > 
 > > Mo, is this needed or is it just a convenience?  Won't the client need 
 > > to track the current stack level and hence can simply adjust/use that 
 > > local copy.
 > 
 > I am not sure what the possible complications of that approach might
 > be. You could assume that the stack level was reset to 0 when a
 > breakpoint was hit and then increment and decrement it. I am
 > not sure what would happen if you started calling inferior functions
 > though. I have seen gdb do things like switch back to the innermost
 > frame after calling an inferior function at some other level of the
 > stack. If that happened, the client would think the stack was one
 > value while gdb could think it was another. I would rather just
 > keep all that info in gdb.

The gui needs to know the current selected frame, in order to update
the windows. If such information is only in gdb wouldn't you end up
making more queries to gdb (one for window/object that needs
updating)?  In theory whenever the level changes, the gui should be
notified. The fact that this does not happen at the moment, because
there is no notification event that gets triggered when the current
frame changes is a deficiency of the MI mechanism, and should be
fixed. (I guess a merge from the MI branch would solve this).

 > 
 > You would also need to assume that the client would not use the
 > frame, up, down and other cli methods via the MI. If they did, the
 > local stack level integer that the client held would be wrong.

Yes, this is the real bug. If this gets fixed, the need for up/down
functionality becomes less compelling.

 > 
 > This just seems like something that should be easy to do via the
 > MI. It is just a way to access up or down like functionality.
 > If you check the existing docs for the -stack-select-frame, it
 > states that up, down, up-silent, and down-silent commands
 > map the -stack-select-frame. My take on the change is that it
 > gets the implementation in line with the documentation.
 > So to sum up, I think it is needed.
 > 

The 'equivalence' is meant to be a loose one. It just means that you
can achieve the same functionality using a combination of 
-stack-select-frame and other commands.
I.e. you can do something like:
-stack-select-frame (current_frame_level - 1)
-stack-select-frame (current_frame_level + 1)

where current_frame_level is obtained from a previous
-stack-info-frame, for instance.  The underlying assumption was that
the GUI should know at all times the current frame level.

Elena



 > cheers
 > Mo