Proposed mod for stack-select-frame MI command

Proposed mod for stack-select-frame MI command

[Mo DeJong]

Greetings

I am been working with the MI recently and ran into a
real problem with the stack-select-frame method.
While it can be used to change the stack to a new level,
there is no way to just move up or down a level(s) like
the cli up and down commands. I am suggesting that
the implementation of the -stack-select-frame be
changed to support selection of stack frames that
are relative to the current stack frame.

-stack-select-frame 0
-stack-select-frame +1
(This would move up one frame)

-stack-select-frame +1
-stack-select-frame -2
(This would end up back at frame 0)

A patch to implement this change has been posted to gdb-patches.

cheers
Mo DeJong

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

[Andrew Cagney]

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.

Andrew


> Greetings
> 
> I am been working with the MI recently and ran into a
> real problem with the stack-select-frame method.
> While it can be used to change the stack to a new level,
> there is no way to just move up or down a level(s) like
> the cli up and down commands. I am suggesting that
> the implementation of the -stack-select-frame be
> changed to support selection of stack frames that
> are relative to the current stack frame.
> 
> -stack-select-frame 0
> -stack-select-frame +1
> (This would move up one frame)
> 
> -stack-select-frame +1
> -stack-select-frame -2
> (This would end up back at frame 0)
> 
> A patch to implement this change has been posted to gdb-patches.
> 
> cheers
> Mo DeJong
> 

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

[Mo DeJong]

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.

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.

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.

cheers
Mo

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

[Keith Seitz]

On Thu, 1 Aug 2002, Mo DeJong wrote:

> 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.

That's not really true anymore. It is right now on cvs HEAD, but in my MI
branch, the MI client would get a frame-level-changed event when the user
used the "up", "down", and "frame" commands from the cli
(-interpreter-exec).

FWIW, I don't think it's necessary, but I wouldn't object to having
this...
Keith

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

[Elena Zannoni]

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