How does GDB/MI give the current frame

How does GDB/MI give the current frame

[Nick Roberts]

Changing the frame with a CLI command (up, down, frame) using annotations
(level 1 or 2), GDB returns an annotation giving the new current frame.
In contrast, the MI command is -stack-select-frame is silent. 

Assuming that future front ends shouldn't use CLI commands, how do you
get the current frame using MI only?

Nick


Context: gdb-ui.el can have a window showing the call stack from which a stack
frame can be made current by selection with the mouse. The displayed source
updates automatically.  I don't see how I can do this with gdb-mi.el without
using the CLI.

Re: How does GDB/MI give the current frame

[Daniel Jacobowitz]

On Thu, Jun 24, 2004 at 11:52:36PM +0100, Nick Roberts wrote:
> 
> Changing the frame with a CLI command (up, down, frame) using annotations
> (level 1 or 2), GDB returns an annotation giving the new current frame.
> In contrast, the MI command is -stack-select-frame is silent. 
> 
> Assuming that future front ends shouldn't use CLI commands, how do you
> get the current frame using MI only?
> 
> Nick
> 
> 
> Context: gdb-ui.el can have a window showing the call stack from which a stack
> frame can be made current by selection with the mouse. The displayed source
> updates automatically.  I don't see how I can do this with gdb-mi.el without
> using the CLI.

Why not use -stack-info-frame?

-- 
Daniel Jacobowitz

Re: How does GDB/MI give the current frame

[Andrew Cagney]

> Changing the frame with a CLI command (up, down, frame) using annotations
> (level 1 or 2), GDB returns an annotation giving the new current frame.
> In contrast, the MI command is -stack-select-frame is silent. 
> 
> Assuming that future front ends shouldn't use CLI commands, how do you
> get the current frame using MI only?
> 
> Nick
> 
> 
> Context: gdb-ui.el can have a window showing the call stack from which a stack
> frame can be made current by selection with the mouse. The displayed source
> updates automatically.  I don't see how I can do this with gdb-mi.el without
> using the CLI

When the user does "up", "down", the debugger should generate a selected 
CLI frame changed event (it currently doesn't).  If the GUI so chooses, 
it can track the users "selected" frame, by responding to these events.

-stack-select-frame, assuming that it changes the CLI's selected frame, 
should generate that same event.   Since the event is identical, the GUI 
can use common event driven code to track both the CLI selected, and GUI 
selected, frames.

One additional note, look at ``Navigating [a]Way'':
http://sources.redhat.com/gdb/papers/multi-arch/real-multi-arch/index.html#SEC25
It should be possible for the GUI to extract frame information from the 
inferior without altering the selected-frame (or selected-thread).  I 
suspect that that currently isn't possible, I also suspect that right 
now you don't need it :-)

Andrew

Re: How does GDB/MI give the current frame

[Nick Roberts]

Daniel Jacobowitz writes:
DJ> 
DJ> Why not use -stack-info-frame?

Because AFAIK this MI command has not been implemented (yet).

Andrew Cagney writes:

AC> When the user does "up", "down", the debugger should generate a selected 
AC> CLI frame changed event (it currently doesn't).  If the GUI so chooses, 
AC> it can track the users "selected" frame, by responding to these events.

I don't know what a selected CLI frame changed event is but up, down, and
frame generate MI output, so I imagine its just a case of hooking
-stack-info-frame and -stack-select-frame to that output. I will try to do
this if you think it's appropriate.

Nick

Re: How does GDB/MI give the current frame

[Daniel Jacobowitz]

On Sat, Jun 26, 2004 at 10:08:41AM +0100, Nick Roberts wrote:
> 
> Daniel Jacobowitz writes:
> DJ> 
> DJ> Why not use -stack-info-frame?
> 
> Because AFAIK this MI command has not been implemented (yet).

So it hasn't!  Silly me, I was fooled by it being documented in the
manual.

> Andrew Cagney writes:
> 
> AC> When the user does "up", "down", the debugger should generate a selected 
> AC> CLI frame changed event (it currently doesn't).  If the GUI so chooses, 
> AC> it can track the users "selected" frame, by responding to these events.
> 
> I don't know what a selected CLI frame changed event is but up, down, and
> frame generate MI output, so I imagine its just a case of hooking
> -stack-info-frame and -stack-select-frame to that output. I will try to do
> this if you think it's appropriate.

I think that Andrew's answering a related question: for debuggers which
allow entry of console commands, the interface needs a way to update
its windows when the user types "up".  Since you're just interested in
MI at the moment, I suspect that filling in -stack-info-frame is the
way to go.

I'm not sure whether -stack-select-frame should have output or not.

-- 
Daniel Jacobowitz

Re: How does GDB/MI give the current frame

[Andrew Cagney]

> Daniel Jacobowitz writes:
> DJ> 
> DJ> Why not use -stack-info-frame?
> 
> Because AFAIK this MI command has not been implemented (yet).
> 
> Andrew Cagney writes:
> 
> AC> When the user does "up", "down", the debugger should generate a selected 
> AC> CLI frame changed event (it currently doesn't).  If the GUI so chooses, 
> AC> it can track the users "selected" frame, by responding to these events.
> 
> I don't know what a selected CLI frame changed event is but up, down, and
> frame generate MI output, so I imagine its just a case of hooking
> -stack-info-frame and -stack-select-frame to that output. I will try to do
> this if you think it's appropriate.

For the CLI, something like this:

-> -interpreter cli "up"
<- ~"info on new frame..."
<- *select-frame,<frame-info>...
<- done

with similar for -stack-select-frame:

-> -stack-select-frame 1
<- *select-frame,<frame-info>,....
<- done

Where, yes, <frame-info> would be constructed by calling frame code.

-stack-info-frame would just be just:

-> -stack-info-frame
<- done,<frame-info>

The important thing is that, in both cases, the GUI is being driven by 
the select-frame event.

Andrew

PS: Better / more consistent event name welcome.

Re: How does GDB/MI give the current frame

[Alain Magloire]

> 
> > Daniel Jacobowitz writes:
> > DJ> 
> > DJ> Why not use -stack-info-frame?
> > 
> > Because AFAIK this MI command has not been implemented (yet).
> > 
> > Andrew Cagney writes:
> > 
> > AC> When the user does "up", "down", the debugger should generate a selected 
> > AC> CLI frame changed event (it currently doesn't).  If the GUI so chooses, 
> > AC> it can track the users "selected" frame, by responding to these events.
> > 
> > I don't know what a selected CLI frame changed event is but up, down, and
> > frame generate MI output, so I imagine its just a case of hooking
> > -stack-info-frame and -stack-select-frame to that output. I will try to do
> > this if you think it's appropriate.
> 
> For the CLI, something like this:
> 
> -> -interpreter cli "up"
> <- ~"info on new frame..."
> <- *select-frame,<frame-info>...
> <- done
> 
> with similar for -stack-select-frame:
> 
> -> -stack-select-frame 1
> <- *select-frame,<frame-info>,....
> <- done
> 
> Where, yes, <frame-info> would be constructed by calling frame code.
> 
> -stack-info-frame would just be just:
> 
> -> -stack-info-frame
> <- done,<frame-info>
> 
> The important thing is that, in both cases, the GUI is being driven by 
> the select-frame event.
> 

Cool !!

One thing:

-thread-select 2
^done,...
-stack-select-frame 3
^done
-thread-select 1
^done,..
-thread-select 2
^done,..

If you would do "-stack-info-frame" now, you would notice that current
stackframe for thread 2 is not longer frame 3 but frame 0 !!
It this case would not it be appropriate to fire a "*select-frame" event.

Second thing:
Playing with MI, I've notice in between -var-update|-var-delete|etc ..
operation the frame selection level was reset to 0, failing the other operations
that was still assuming a certain frame level.
Now is this an appropriate behaviour? or a bug? if it is appropriate should
client recall -stack-select-frame XX all the time to make sure things are ok

> Andrew
> 
> PS: Better / more consistent event name welcome.
> 

How about to put the thread-id part ot the event ?

Re: How does GDB/MI give the current frame

[Nick Roberts]

 > > For the CLI, something like this:
 > > 
 > > -> -interpreter cli "up"
 > > <- ~"info on new frame..."
 > > <- *select-frame,<frame-info>...
 > > <- done
 > > 
 > > with similar for -stack-select-frame:
 > > 
 > > -> -stack-select-frame 1
 > > <- *select-frame,<frame-info>,....
 > > <- done
 > > 
 > > Where, yes, <frame-info> would be constructed by calling frame code.
 > > 
 > > -stack-info-frame would just be just:
 > > 
 > > -> -stack-info-frame
 > > <- done,<frame-info>
 > > 
 > > The important thing is that, in both cases, the GUI is being driven by 
 > > the select-frame event.
 > > 
 > 
 > Cool !!
 > 
 > One thing:
 > 
 > -thread-select 2
 > ^done,...
 > -stack-select-frame 3
 > ^done
 > -thread-select 1
 > ^done,..
 > -thread-select 2
 > ^done,..
 > 
 > If you would do "-stack-info-frame" now, you would notice that current
 > stackframe for thread 2 is not longer frame 3 but frame 0 !!
 > It this case would not it be appropriate to fire a "*select-frame" event.

There would still be problems with displaying the values of variables.
Neither variable objects or the CLI command, display, seem to take
notice of the thread number.

Nick

Re: How does GDB/MI give the current frame

[Andrew Cagney]

>  > > For the CLI, something like this:
>  > > 
>  > > -> -interpreter cli "up"
>  > > <- ~"info on new frame..."
>  > > <- *select-frame,<frame-info>...
>  > > <- done

Note that the interpreter case is key, it lets the GUI respond to 
operations on the command line.

>  > > with similar for -stack-select-frame:
>  > > 
>  > > -> -stack-select-frame 1
>  > > <- *select-frame,<frame-info>,....
>  > > <- done
>  > > 
>  > > Where, yes, <frame-info> would be constructed by calling frame code.
>  > > 
>  > > -stack-info-frame would just be just:
>  > > 
>  > > -> -stack-info-frame
>  > > <- done,<frame-info>
>  > > 
>  > > The important thing is that, in both cases, the GUI is being driven by 
>  > > the select-frame event.
>  > > 
>  > 
>  > Cool !!
>  > 
>  > One thing:
>  > 
>  > -thread-select 2
>  > ^done,...
>  > -stack-select-frame 3
>  > ^done
>  > -thread-select 1
>  > ^done,..
>  > -thread-select 2
>  > ^done,..
>  > 
>  > If you would do "-stack-info-frame" now, you would notice that current
>  > stackframe for thread 2 is not longer frame 3 but frame 0 !!
>  > It this case would not it be appropriate to fire a "*select-frame" event.
> 
> There would still be problems with displaying the values of variables.
> Neither variable objects or the CLI command, display, seem to take
> notice of the thread number.

``bug'' in current MI protocol.  How would something like:

-thread 2 -<something else>
^done
-thread 2 -frame 3 -<something else>
-frame 3 -<something else>
^done

grab you?   ``-thread'' and ``-frame'' select the thread/frame for 
_just_ the period of that command.  They would not alter the CLI's 
selected thread/frame (the implementation would for the moment need to 
be a crock but thats a separate problem :-).

This would let the GUI manipulate frames independant of the CLI.

> Second thing:
> Playing with MI, I've notice in between -var-update|-var-delete|etc ..
> operation the frame selection level was reset to 0, failing the other operations
> that was still assuming a certain frame level.
> Now is this an appropriate behaviour? or a bug? if it is appropriate should
> client recall -stack-select-frame XX all the time to make sure things are ok

``bug''.  Actually major screwup in how GDB models threads (as in it 
doesn't really :-)

> How about to put the thread-id part ot the event ?

So the event would be ``selected changed'' and generated when both 
switching threads and frames?  If it is useful, ok.

Andrew

Re: How does GDB/MI give the current frame

[Alain Magloire]

> 
> >  > > For the CLI, something like this:
> >  > > 
> >  > > -> -interpreter cli "up"
> >  > > <- ~"info on new frame..."
> >  > > <- *select-frame,<frame-info>...
> >  > > <- done
> 
> Note that the interpreter case is key, it lets the GUI respond to 
> operations on the command line.
> 

Absolutely!!

> >  > One thing:
> >  > 
> >  > -thread-select 2
> >  > ^done,...
> >  > -stack-select-frame 3
> >  > ^done
> >  > -thread-select 1
> >  > ^done,..
> >  > -thread-select 2
> >  > ^done,..
> >  > 
> >  > If you would do "-stack-info-frame" now, you would notice that current
> >  > stackframe for thread 2 is not longer frame 3 but frame 0 !!
> >  > It this case would not it be appropriate to fire a "*select-frame" event.
> > 
> > There would still be problems with displaying the values of variables.
> > Neither variable objects or the CLI command, display, seem to take
> > notice of the thread number.
> 

Nic, are you using the -var-obj for variables, in theory they
have the context i.e. should be thread aware ?

> ``bug'' in current MI protocol.  How would something like:
> 
> -thread 2 -<something else>
> ^done
> -thread 2 -frame 3 -<something else>
> -frame 3 -<something else>
> ^done
> 
> grab you?   ``-thread'' and ``-frame'' select the thread/frame for 
> _just_ the period of that command.  They would not alter the CLI's 
> selected thread/frame (the implementation would for the moment need to 
> be a crock but thats a separate problem :-).
> 
> This would let the GUI manipulate frames independant of the CLI.
> 
> > Second thing:
> > Playing with MI, I've notice in between -var-update|-var-delete|etc ..
> > operation the frame selection level was reset to 0, failing the other operations
> > that was still assuming a certain frame level.
> > Now is this an appropriate behaviour? or a bug? if it is appropriate should
> > client recall -stack-select-frame XX all the time to make sure things are ok
> 
> ``bug''.  Actually major screwup in how GDB models threads (as in it 
> doesn't really :-)
> 

8-) ok.

> > How about to put the thread-id part ot the event ?
> 
> So the event would be ``selected changed'' and generated when both 
> switching threads and frames?  If it is useful, ok.
> 

If you are asking if we would want an event for thread selection
the same as for frame selection ...  The answer is a strong "Yes".

Our problems is coordinating the mix of CLI and UI driven actions
so things are in sync.  So if the user select a new thread via
the command line, variables and all othe related views should be updated.

The hard lesson learn from the last CDT/Debug release, is that the 
command prompt will stay and the users(allthough not a majority) that
wanted this feature ... are __very__ vocal.

Re: How does GDB/MI give the current frame

[Nick Roberts]

 > Nic, are you using the -var-obj for variables, in theory they
 > have the context i.e. should be thread aware ?

Ah yes, I can see that now. It seems a bit quirky and that you have to
do a -var-update for each thread. Also there's no way of seeing which
thread the variable object is for:

-var-info-expression var1
^done,lang="C",exp="y"
(gdb) 
-var-info-expression var2
^done,lang="C",exp="y"
(gdb) 

Nick

Re: How does GDB/MI give the current frame

[Nick Roberts]

 > >  > > -> -interpreter cli "up"
 > >  > > <- ~"info on new frame..."
 > >  > > <- *select-frame,<frame-info>...
 > >  > > <- done
 > 
 > Note that the interpreter case is key, it lets the GUI respond to 
 > operations on the command line.

On my gdb, -interpreter-exec cli "up" gives:

^error,msg="mi_cmd_interpreter_exec: could not find interpreter \"cli\""
(gdb) 

I'm still lost here.

 > > There would still be problems with displaying the values of variables.
 > > Neither variable objects or the CLI command, display, seem to take
 > > notice of the thread number.
 > 
 > ``bug'' in current MI protocol.  How would something like:
 > 
 > -thread 2 -<something else>
 > ^done
 > -thread 2 -frame 3 -<something else>
 > -frame 3 -<something else>
 > ^done

Or values could be printed for all threads:

-var-evaluate-expression var1
^done,values=[{thread-id="0",value="0"},{thread-id="1",value="4"},...]

and likewise for other mi commands. This would have the disadvantage of
breaking existing behaviour but I imagine a user might want to see the value
of a variable across all threads and would not wish to create a variable
object for each thread.

Nick

Re: How does GDB/MI give the current frame

[Andrew Cagney]

>  > >  > > -> -interpreter cli "up"
>  > >  > > <- ~"info on new frame..."
>  > >  > > <- *select-frame,<frame-info>...
>  > >  > > <- done
>  > 
>  > Note that the interpreter case is key, it lets the GUI respond to 
>  > operations on the command line.
> 
> On my gdb, -interpreter-exec cli "up" gives:
> 
> ^error,msg="mi_cmd_interpreter_exec: could not find interpreter \"cli\""
> (gdb) 
> 
> I'm still lost here.

Sorry s/cli/console/, teach me to write something from memory.

>  > > There would still be problems with displaying the values of variables.
>  > > Neither variable objects or the CLI command, display, seem to take
>  > > notice of the thread number.
>  > 
>  > ``bug'' in current MI protocol.  How would something like:
>  > 
>  > -thread 2 -<something else>
>  > ^done
>  > -thread 2 -frame 3 -<something else>
>  > -frame 3 -<something else>
>  > ^done
> 
> Or values could be printed for all threads:
> 
> -var-evaluate-expression var1
> ^done,values=[{thread-id="0",value="0"},{thread-id="1",value="4"},...]
> 
> and likewise for other mi commands. This would have the disadvantage of
> breaking existing behaviour but I imagine a user might want to see the value
> of a variable across all threads and would not wish to create a variable
> object for each thread.

For existing commands, I don't get warm fuzzies.  Assuming that the GUI 
is only displaying one thread, there's no need to supply the value 
across all threads.

As an extension, I guess, why not.  Something like:

-thread-apply 1 2 3 4 -- -something
^done,result=[{thread-id="1",result=<result>},{thread-id="2",error=<something>},...]

or

-thread-apply * -- -something
^done,result=[{thread-id="1",result=...},...]

that is, it returns a list of results from each individual command - 
that makes more sense.

Andrew

Re: How does GDB/MI give the current frame

[Alain Magloire]

> 
> 
>  > Nic, are you using the -var-obj for variables, in theory they
>  > have the context i.e. should be thread aware ?
> 
> Ah yes, I can see that now. It seems a bit quirky and that you have to
> do a -var-update for each thread. Also there's no way of seeing which
> thread the variable object is for:
> 
> -var-info-expression var1
> ^done,lang="C",exp="y"
> (gdb) 
> -var-info-expression var2
> ^done,lang="C",exp="y"
> (gdb) 
> 

Interesting idea.  For now, we(the front-end) send
 -var-update varxxx
when a new thread is selected. (Can not use -var-update "*", for
some reasone it gets all strange/bizarre if varobj are created for registers too).

Curious, what do you want to accomplish with this, or rather how do
you intend to use it in you emacs port ?

Re: How does GDB/MI give the current frame

[Nick Roberts]

Andrew Cagney writes:
 > >  > >  > > -> -interpreter cli "up"
 > >  > >  > > <- ~"info on new frame..."
 > >  > >  > > <- *select-frame,<frame-info>...
 > >  > >  > > <- done
 > >  > 
 > >  > Note that the interpreter case is key, it lets the GUI respond to 
 > >  > operations on the command line.
 > > 
 > > On my gdb, -interpreter-exec cli "up" gives:
 > > 
 > > ^error,msg="mi_cmd_interpreter_exec: could not find interpreter \"cli\""
 > > (gdb) 
 > > 
 > > I'm still lost here.
 > 
 > Sorry s/cli/console/, teach me to write something from memory.

In that case, I disagree strongly with the suggestion since I think that
"-interpreter-exec console" should only give quoted CLI output (plus prefix
character). I thought that was the whole idea as it allows front ends to keep
the console. Typing CLI input in directly currently gives a mixture of CLI/MI
output but this is fine as it is only a temporary/ad hoc means of accessing
the CLI. In Emacs, I will run commands from the console with
"-interpreter-exec console" and check the status of gdb with a set of MI
commands run behind the users back. I imagine a lot of others will do the
same, so please don't change this.

Earlier, you said

> with similar for -stack-select-frame:

> -> -stack-select-frame 1
> <- *select-frame,<frame-info>,....
> <- done

Can you elaborate? How does "*select-frame" get printed? Does it trigger
anything internally?

 > >  >                          ....  How would something like:
 > >  > 
 > >  > -thread 2 -<something else>
 > >  > ^done
 > >  > -thread 2 -frame 3 -<something else>
 > >  > -frame 3 -<something else>
 > >  > ^done
 > > 
 > > Or values could be printed for all threads:
 > > 
 > > -var-evaluate-expression var1
 > > ^done,values=[{thread-id="0",value="0"},{thread-id="1",value="4"},...]
 > > 
 > > and likewise for other mi commands. This would have the disadvantage of
 > > breaking existing behaviour but I imagine a user might want to see the value
 > > of a variable across all threads and would not wish to create a variable
 > > object for each thread.
 > 
 > For existing commands, I don't get warm fuzzies.  Assuming that the GUI 
 > is only displaying one thread, there's no need to supply the value 
 > across all threads.
 > 
 > As an extension, I guess, why not.  Something like:
 > 
 > -thread-apply 1 2 3 4 -- -something
 > ^done,result=[{thread-id="1",result=<result>},{thread-id="2",error=<something>},...]
 > 
 > or
 > 
 > -thread-apply * -- -something
 > ^done,result=[{thread-id="1",result=...},...]
 > 
 > that is, it returns a list of results from each individual command - 
 > that makes more sense.

Yes, that sounds like a good idea. Is it easy to implement?

Nick

Re: How does GDB/MI give the current frame

[Nick Roberts]

 > Curious, what do you want to accomplish with this, or rather how do
 > you intend to use it in you emacs port ?

gdb-ui.el in the Emacs CVS repository already uses variable objects. I would
like Emacs to have features for debugging multi-threaded programs like those
found in the Totalview debugger.

Nick

Re: How does GDB/MI give the current frame

[Andrew Cagney]

> Andrew Cagney writes:
>  > >  > >  > > -> -interpreter cli "up"
>  > >  > >  > > <- ~"info on new frame..."
>  > >  > >  > > <- *select-frame,<frame-info>...
>  > >  > >  > > <- done
>  > >  > 
>  > >  > Note that the interpreter case is key, it lets the GUI respond to 
>  > >  > operations on the command line.
>  > > 
>  > > On my gdb, -interpreter-exec cli "up" gives:
>  > > 
>  > > ^error,msg="mi_cmd_interpreter_exec: could not find interpreter \"cli\""
>  > > (gdb) 
>  > > 
>  > > I'm still lost here.
>  > 
>  > Sorry s/cli/console/, teach me to write something from memory.
> 
> In that case, I disagree strongly with the suggestion since I think that
> "-interpreter-exec console" should only give quoted CLI output (plus prefix
> character). I thought that was the whole idea as it allows front ends to keep
> the console. Typing CLI input in directly currently gives a mixture of CLI/MI
> output but this is fine as it is only a temporary/ad hoc means of accessing
> the CLI.

(Looks like my yesterday reply died along with my battery :-()

That's almost the whole idea.  The -interpreter-exec command provides 
two mechanism to the GUI/client:

- the ability to access GDB's `console' vis:
	-> -interpreter cli "up"
	<- ~"info on new frame..."
	<- done

- the ability to notify the GUI of console sideeffects vis:
	<- *select-frame,<frame-info>...

 > In Emacs, I will run commands from the console with
 > "-interpreter-exec console" and check the status of gdb with a set of MI
 > commands run behind the users back. I imagine a lot of others will do the
 > same, so please don't change this.

Wouldn't these polling commands need to be run behind the users back 
after every CLI command?  By monitoring these events, the GUI can avoid 
polling except when needed.

> Earlier, you said
> 
> 
>>> with similar for -stack-select-frame:
> 
> 
>>> -> -stack-select-frame 1
>>> <- *select-frame,<frame-info>,....
>>> <- done
> 
> 
> Can you elaborate? How does "*select-frame" get printed? Does it trigger
> anything internally?

An observer would be needed.

>  > >  >                          ....  How would something like:
>  > >  > 
>  > >  > -thread 2 -<something else>
>  > >  > ^done
>  > >  > -thread 2 -frame 3 -<something else>
>  > >  > -frame 3 -<something else>
>  > >  > ^done
>  > > 
>  > > Or values could be printed for all threads:
>  > > 
>  > > -var-evaluate-expression var1
>  > > ^done,values=[{thread-id="0",value="0"},{thread-id="1",value="4"},...]
>  > > 
>  > > and likewise for other mi commands. This would have the disadvantage of
>  > > breaking existing behaviour but I imagine a user might want to see the value
>  > > of a variable across all threads and would not wish to create a variable
>  > > object for each thread.
>  > 
>  > For existing commands, I don't get warm fuzzies.  Assuming that the GUI 
>  > is only displaying one thread, there's no need to supply the value 
>  > across all threads.
>  > 
>  > As an extension, I guess, why not.  Something like:
>  > 
>  > -thread-apply 1 2 3 4 -- -something
>  > ^done,result=[{thread-id="1",result=<result>},{thread-id="2",error=<something>},...]
>  > 
>  > or
>  > 
>  > -thread-apply * -- -something
>  > ^done,result=[{thread-id="1",result=...},...]
>  > 
>  > that is, it returns a list of results from each individual command - 
>  > that makes more sense.
> 
> Yes, that sounds like a good idea. Is it easy to implement?

It should be fairly straight forward.  Have a look at ``info threads''.

Andrew

Re: How does GDB/MI give the current frame

[Nick Roberts]

 > That's almost the whole idea.  The -interpreter-exec command provides 
 > two mechanism to the GUI/client:
 > 
 > - the ability to access GDB's `console' vis:
 > 	-> -interpreter cli "up"
 > 	<- ~"info on new frame..."
 > 	<- done
 > 
 > - the ability to notify the GUI of console sideeffects vis:
 > 	<- *select-frame,<frame-info>...

That sounds like a third interface. This is an elegant approach but assumes
that someone will implement the notification for every CLI command that has
side effects. This seems unlikely in the current circumstances

 >  > In Emacs, I will run commands from the console with
 >  > "-interpreter-exec console" and check the status of gdb with a set of MI
 >  > commands run behind the users back. I imagine a lot of others will do the
 >  > same, so please don't change this.
 > 
 > Wouldn't these polling commands need to be run behind the users back 
 > after every CLI command?  By monitoring these events, the GUI can avoid 
 > polling except when needed.

Yes, so I guess it will be slower. It just seems a realistic starting point.
It would only need a handful of MI commands to give the rough status of GDB:

-var-update
-break-list
-stack-list-locals
-stack-list-frames
-stack-info-frame  (not implemented yet)

The MI output on the "-interpreter-exec console" command could be added later
if wished. I think it would need to be done in a co-ordinated fashion not
piecemeal, however.

Nick

Re: How does GDB/MI give the current frame

[Jason Molenda]

On Jul 15, 2004, at 12:45 PM, Nick Roberts wrote:

>> That's almost the whole idea.  The -interpreter-exec command provides
>> two mechanism to the GUI/client:
>>
>> - the ability to access GDB's `console' vis:
>> 	-> -interpreter cli "up"
>> 	<- ~"info on new frame..."
>> 	<- done
>>
>> - the ability to notify the GUI of console sideeffects vis:
>> 	<- *select-frame,<frame-info>...
>
> That sounds like a third interface. This is an elegant approach but  
> assumes
> that someone will implement the notification for every CLI command  
> that has
> side effects. This seems unlikely in the current circumstances


For what it's worth, at Apple we've done what Andrew is proposing.  Our  
method spits out a "MI_HOOK_RESULT" notification on the ^done result  
whenever the console command entered by the user has changed the state  
in an important way.  e.g.

(gdb)
-interpreter-exec console-quoted up
~"#2  0x000321f4 in gdb_main (args=0xbffff620) at  
../../gdb/src/gdb/main.c:851\n"
~"851\t  catch_errors (captured_main, args, \"\", RETURN_MASK_ALL);\n"
^done,MI_HOOK_RESULT=[HOOK_TYPE="frame_changed",frame="2"],time= 
{wallclock="0.00620",user="0.00323",system="0.00283",start="1089921236.3 
59009",end="1089921236.365212"}
(gdb)


(Ignore the "console-quoted"  -- we have a separate interpreter for  
console output marshalled through the MI quoting rules)

(and ignore the time= thing at the end; that's a little internal debug  
thing we use to track down performance problems more easily between gdb  
an the UI.  Our UI has a feature where it saves all MI text to a file  
for debugging; it's *invaluable* for tracking down bugs and our UI  
timestamps its own logging messages so we can tell whether the UI or  
gdb is being slow when we get reports of slowness.)


FWIW, here's the list of notification hooks we currently generate:  
breakpoint_create, breakpoint_modify, breakpoint_delete, stack_changed,  
frame_changed, thread_changed.


J

Re: How does GDB/MI give the current frame

[Jason Molenda]

On Jul 15, 2004, at 1:04 PM, Jason Molenda wrote:

> For what it's worth, at Apple we've done what Andrew is proposing.   
> Our method spits out a "MI_HOOK_RESULT" notification on the ^done  
> result whenever the console command entered by the user has changed  
> the state in an important way.  e.g.

[...]

>
> FWIW, here's the list of notification hooks we currently generate:  
> breakpoint_create, breakpoint_modify, breakpoint_delete,  
> stack_changed, frame_changed, thread_changed.
>

I should add that we also call output_control_change_notification()  
with "stepping" or "continuing" when the user enters a console command  
that resumes execution.  e.g.

(gdb)
-interpreter-exec console-quoted step
^stepping
^running
(gdb)
*stopped,time= 
{wallclock="0.01470",user="0.00635",system="0.00845",start="1089922425.6 
47144",end="1089922425.661845"},reason="end-stepping-range",thread- 
id="1"
(gdb)
-interpreter-exec console-quoted continue
~"Continuing.\n"
^continuing
^running

So the UI knows when the user is resuming the inferior behind its back.


J

Re: How does GDB/MI give the current frame

[Alain Magloire]

> 
> 
> On Jul 15, 2004, at 12:45 PM, Nick Roberts wrote:
> 
> >> That's almost the whole idea.  The -interpreter-exec command provides
> >> two mechanism to the GUI/client:
> >>
> >> - the ability to access GDB's `console' vis:
> >> 	-> -interpreter cli "up"
> >> 	<- ~"info on new frame..."
> >> 	<- done
> >>
> >> - the ability to notify the GUI of console sideeffects vis:
> >> 	<- *select-frame,<frame-info>...
> >
> > That sounds like a third interface. This is an elegant approach but  
> > assumes
> > that someone will implement the notification for every CLI command  
> > that has
> > side effects. This seems unlikely in the current circumstances
> 
> 
> For what it's worth, at Apple we've done what Andrew is proposing.  Our  
> method spits out a "MI_HOOK_RESULT" notification on the ^done result  
> whenever the console command entered by the user has changed the state  
> in an important way.  e.g.
> 
> (gdb)
> -interpreter-exec console-quoted up
> ~"#2  0x000321f4 in gdb_main (args=0xbffff620) at  
> ../../gdb/src/gdb/main.c:851\n"
> ~"851\t  catch_errors (captured_main, args, \"\", RETURN_MASK_ALL);\n"
> ^done,MI_HOOK_RESULT=[HOOK_TYPE="frame_changed",frame="2"],time= 
> {wallclock="0.00620",user="0.00323",system="0.00283",start="1089921236.3 
> 59009",end="1089921236.365212"}
> (gdb)
> 

But what Andrew is proposing is to use the async-output already part of MI to notify
the UI of changes.
What you are showing here is this new MI_HOOK_RESULT, unless the output is missing lines ?

> 
> 
> FWIW, here's the list of notification hooks we currently generate:  
> breakpoint_create, breakpoint_modify, breakpoint_delete, stack_changed,  
> frame_changed, thread_changed.
> 

Cool !

Re: How does GDB/MI give the current frame

[Alain Magloire]

> 
> 
> On Jul 15, 2004, at 1:04 PM, Jason Molenda wrote:
> 
> > For what it's worth, at Apple we've done what Andrew is proposing.   
> > Our method spits out a "MI_HOOK_RESULT" notification on the ^done  
> > result whenever the console command entered by the user has changed  
> > the state in an important way.  e.g.
> 
> [...]
> 
> >
> > FWIW, here's the list of notification hooks we currently generate:  
> > breakpoint_create, breakpoint_modify, breakpoint_delete,  
> > stack_changed, frame_changed, thread_changed.
> >
> 


how about for "set p 3", changing values.

> I should add that we also call output_control_change_notification()  
> with "stepping" or "continuing" when the user enters a console command  
> that resumes execution.  e.g.
> 
> (gdb)
> -interpreter-exec console-quoted step
> ^stepping
> ^running
> (gdb)
> *stopped,time= 
> {wallclock="0.01470",user="0.00635",system="0.00845",start="1089922425.6 
> 47144",end="1089922425.661845"},reason="end-stepping-range",thread- 
> id="1"
> (gdb)
> -interpreter-exec console-quoted continue
> ~"Continuing.\n"
> ^continuing
> ^running
> 

Good !!
Few questions why "console-quoted", what's wrong with "console" or rather
what is -quoted provide more ?

What's "^continuing" ? a way to discovered the type of command enter by the user ?
so "^stepping" for step etc ... is it usefull ?
> So the UI knows when the user is resuming the inferior behind its back.
> 
> 
> J
> 


-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!

Re: How does GDB/MI give the current frame

[Nick Roberts]

 > > For what it's worth, at Apple we've done what Andrew is proposing.  Our  
 > > method spits out a "MI_HOOK_RESULT" notification on the ^done result  
 > > whenever the console command entered by the user has changed the state  
 > > in an important way.  e.g.
 > > 
 > > (gdb)
 > > -interpreter-exec console-quoted up
 > > ~"#2  0x000321f4 in gdb_main (args=0xbffff620) at  
 > > ../../gdb/src/gdb/main.c:851\n"
 > > ~"851\t  catch_errors (captured_main, args, \"\", RETURN_MASK_ALL);\n"
 > > ^done,MI_HOOK_RESULT=[HOOK_TYPE="frame_changed",frame="2"],time= 
 > > {wallclock="0.00620",user="0.00323",system="0.00283",start="1089921236.3 
 > > 59009",end="1089921236.365212"}
 > > (gdb)
 > > 
 > 
 > But what Andrew is proposing is to use the async-output already part of MI to notify
 > the UI of changes.

Wouldn't the output from "up" would be synchronous? I thought asynchronous output
only occurs when the inferior is actually running.

Nick

Re: How does GDB/MI give the current frame

[Andrew Cagney]

>  > > For what it's worth, at Apple we've done what Andrew is proposing.  Our  
>  > > method spits out a "MI_HOOK_RESULT" notification on the ^done result  
>  > > whenever the console command entered by the user has changed the state  
>  > > in an important way.  e.g.
>  > > 
>  > > (gdb)
>  > > -interpreter-exec console-quoted up
>  > > ~"#2  0x000321f4 in gdb_main (args=0xbffff620) at  
>  > > ../../gdb/src/gdb/main.c:851\n"
>  > > ~"851\t  catch_errors (captured_main, args, \"\", RETURN_MASK_ALL);\n"
>  > > ^done,MI_HOOK_RESULT=[HOOK_TYPE="frame_changed",frame="2"],time= 
>  > > {wallclock="0.00620",user="0.00323",system="0.00283",start="1089921236.3 
>  > > 59009",end="1089921236.365212"}
>  > > (gdb)
>  > > 
>  > 
>  > But what Andrew is proposing is to use the async-output already part of MI to notify
>  > the UI of changes.
> 
> Wouldn't the output from "up" would be synchronous? I thought asynchronous output
> only occurs when the inferior is actually running.

Moving forward, that won't be a good assumption.  Of the top of my head:

- part of the inferior is still running

- something else also connected to gdb asks gdb to do an "up" (see 
moto's question about flushing gdb's internal state when the system is 
stopped and hence shouldn't need a flush.)

Andrew