Queries in MI

[Jim Ingham]

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