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