This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: How does GDB/MI give the current frame
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