This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Queries in MI

Oops, I beg your pardon. Apparently we didn't implement this for query.

The area we did implement user input for was the "command" and "define" commands. I don't remember now why we didn't use the same mechanism for query, it would have been easy to do that... Anyway, for "command" it looks something like:

-> 81-interpreter-exec console-quoted "commands 1"
<- (gdb)
<- =read-one-line,prompt=">"
-> print self
<- =read-one-line,prompt=">"
-> end
<- 81^done,time= {wallclock="7.87027",user="0.00050",system="0.00040",start="1120843556.1 42967",end="1120843564.013233"}

This is the log format that Xcode spits out. The lines with the -> are commands sent to gdb. The lines with the <- lines sent back to Xcode. The request for a line of input is an asynchronous message from gdb, which seems correct to me.

We do this by hooking into the "command_line_input hook". I don't remember now why we didn't do the same thing for the query_hook. Probably we just forgot.

Jim

On Jul 8, 2005, at 9:36 AM, Alain Magloire wrote:




-----Original Message-----
From: gdb-owner@sources.redhat.com [mailto:gdb- owner@sources.redhat.com]
On Behalf Of Jim Ingham
Sent: Thursday, July 07, 2005 2:10 PM
To: gdb@sources.redhat.com
Subject: Re: Queries in MI

Seems to me like the need for query responses from the Front End
comes in two categories.  One is things that are predictable, like
the question "do you want to set undefined breakpoints".  Or when you
re-run with the executable still running and gdb asks whether you
want to terminate the target.  In these cases, the MI command should
be crafted to allow the FE to select one choice or the other, and the
default should be something reasonable.  There's no reason to support
a query here, the FE should be able to figure out what it wants in
advance and just do it.

The other is when the Front End can't a priori know enough to make a
decision.  The only example we've come across so far is with
breakpoints that resolve to multiple choices.  In that case, what we
do is we don't set any breakpoints, but return a list of choices to
the UI instead.  Then I've tarted up the -break-insert so that it
will take a selection list as well, and if the selection list is
there, it will choose those options from the list.  What we did is a
little weak in that I don't verify that the breakpoint expression you
send back with the selection list is the same as the one you sent
when I generated the list.  But that was complicated to do, and I was
pretty sure we could trust the FE not to willfully shoot itself in
the foot here...

This way, we don't have to keep stateful interactions suspended
between the UI & the FE, which seemed a more robust design to me.

I don't think I see any cases of queries that can't be handled this way.

Of course, you have to make sure that commands issued with "-
interpreter-exec console" return the queries to the console properly,
that's a separate issue.  That works in our gdb, but I don't remember
whether Keith, Elena et al merged all this stuff over or not.



Good question...
But it this case what we ending doing is check for the prompt(the secondary
prompt, usually ">") and allow the user to finish by entering commands
Without any interpretation. This very weak and prone to since for that
case we our at the mercy of the user to finish the sequence, any other
Command form the FE will interfere with this.
It would be nice for the next version of MI to handle this a little more
Elegantly. Based on you experience with MI did you have any thoughts ?


Jim

On Jul 7, 2005, at 1:16 AM, gdb-digest-help@sources.redhat.com wrote:






I'm not sure what you're suggesting, but Emacs will always want
to allow
CLI input through the GUD buffer which, for example, will be
forwarded to
GDB as:

-interpreter-exec console "b asdf"



Of course. Your stating the case when the user sends a command to GDB
and get's a query as a response. That's fine.

What about the case when the FE sends a command to GDB and has to
deal
with the query? That isn't capable with the current output. The MI
response would have to have the query information built into it,
like,

-break-insert "b asdf"
^done,query={choice1="...",choice2="..."}
FE sends->choice1
...



Well "b asdf" is a CLI command, but I take your point. Currently,
if asdf is
symbol that is in a shared library that is yet to be loaded, then

(gdb)
-break-insert asdf
&"Function \"asdf\" not defined.\n"
^done
(gdb)

This is the opposite behaviour to -interpreter-exec console "b asdf"
and the same as you would you would get using CLI with "set confirm
off".



I currently don't have a need for such a feature, but I'm just
suggesting that the current mechanism doesn't allow the FE to do this
sort of thing nicely. I'm sure it will be needed eventually.



You're suggesting a syntax.  I'm not sure what the mechanism should
be,
because if GDB is made to wait for a response that might break other
things.

Nick



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]