MI usage inside a user-defined commands

MI usage inside a user-defined commands

[Karganov Konstantin]

Hello, all.

It seems that user-defined commands are always parsed by console cmd-line 
interpreter (no matter what interpreter was specified).
I tried to print a variable from the user-defined cmd and directly from 
the interpreter:

(gdb)
define aaaa
&"define aaaa\n"
>-data-evaluate-expression i
>end
^done
(gdb)
aaaa
&"aaaa\n"
&"Undefined command: \"-data-evaluate-expression\".  Try \"help\".\n"
^error,msg="Undefined command: \"-data-evaluate-expression\".  Try 
\"help\"."
(gdb)
-data-evaluate-expression i
^done,value="0"
(gdb)

I use gdb 6.3 built from sources on RedHat 9. Debug session is started as 
"gdb --i=mi a.out"

Is is a bug or a feature?

Best regards,
Konstantin.

Re: MI usage inside a user-defined commands

[Daniel Jacobowitz]

On Wed, Jul 06, 2005 at 04:16:52PM +0400, Karganov Konstantin wrote:
> Hello, all.
> 
> It seems that user-defined commands are always parsed by console cmd-line 
> interpreter (no matter what interpreter was specified).

Yes, that's correct.  define is a feature of the CLI, not of core GDB.
I think this is as designed.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: MI usage inside a user-defined commands

[Karganov Konstantin]

> > It seems that user-defined commands are always parsed by console cmd-line 
> > interpreter (no matter what interpreter was specified).
> 
> Yes, that's correct.  define is a feature of the CLI, not of core GDB.
> I think this is as designed.

This looks a little bit strange - when I switch to MI I can use both MI 
and CLI syntax but suddenly get a error with MI command ("hey! I've just 
switched to MI mode! what's the..."). 

I mean the "define" feature itself works fine under MI (that is expected), 
but allows only CLI commands inside (that is not expected). From the first 
view it looks like broken CLI-compatibility...

Best regards,
Konstantin.

Re: MI usage inside a user-defined commands

[Daniel Jacobowitz]

On Wed, Jul 06, 2005 at 05:32:22PM +0400, Karganov Konstantin wrote:
> 
> > > It seems that user-defined commands are always parsed by console cmd-line 
> > > interpreter (no matter what interpreter was specified).
> > 
> > Yes, that's correct.  define is a feature of the CLI, not of core GDB.
> > I think this is as designed.
> 
> This looks a little bit strange - when I switch to MI I can use both MI 
> and CLI syntax but suddenly get a error with MI command ("hey! I've just 
> switched to MI mode! what's the..."). 

The ability to use CLI syntax in MI mode is documented in the manual as
an unsupported, transitional feature.  It's for your convenience when
poking at MI by hand - it's not to be used by frontends.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: MI usage inside a user-defined commands

[Karganov Konstantin]

> The ability to use CLI syntax in MI mode is documented in the manual as
> an unsupported, transitional feature.
It is documented, that "MI accepts existing CLI commands" (section 24.4) 
and nothing is said about "unsupported" or "transitional" :)

> it's not to be used by frontends.
That is clear, since the output format will be the mess of CLI and MI 
output.

Best regards,
Konstantin.

Re: MI usage inside a user-defined commands

[Karganov Konstantin]

> The ability to use CLI syntax in MI mode is documented in the manual as
> an unsupported, transitional feature.
By the way, the -gdb-set command is described as "Set an internal GDB 
variable. The corresponding GDB command is set".
From the description it is unclear - is "-gdb-set var" an ocasional 
undocumented feature or the correct way of setting program variables.

I suggest it's better for the docs to state this explicitly.

Best regards,
Konstantin.

Re: MI usage inside a user-defined commands

[Daniel Jacobowitz]

On Thu, Jul 07, 2005 at 04:06:48PM +0400, Karganov Konstantin wrote:
> 
> > The ability to use CLI syntax in MI mode is documented in the manual as
> > an unsupported, transitional feature.
> By the way, the -gdb-set command is described as "Set an internal GDB 
> variable. The corresponding GDB command is set".
> From the description it is unclear - is "-gdb-set var" an ocasional 
> undocumented feature or the correct way of setting program variables.
> 
> I suggest it's better for the docs to state this explicitly.

I don't know the intention - but usually, to manipulate program
variables in MI, one uses varobj.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: MI usage inside a user-defined commands

[Karganov Konstantin]

> I don't know the intention - but usually, to manipulate program
> variables in MI, one uses varobj.
I know.
But it seems too much fuss to create a varobj, assign a value and delete 
it when I need just to raise a flag in a debugged program...

Best regards,
Konstantin.

Re: MI usage inside a user-defined commands

[Nick Roberts]

 > > I don't know the intention - but usually, to manipulate program
 > > variables in MI, one uses varobj.
 > I know.
 > But it seems too much fuss to create a varobj, assign a value and delete 
 > it when I need just to raise a flag in a debugged program...

The implementation of -gdb-set currently does use CLI but it is still
presented as an MI command.  So, although the implementation might change, I
see no reason for the command itself to disappear.  Since the documentation
doesn't suggest it is temporary or should not be used for program variables, I
would use this command if it is more convenient.

Nick

Re: MI usage inside a user-defined commands

[Nick Roberts]

 > I mean the "define" feature itself works fine under MI (that is expected), 
 > but allows only CLI commands inside (that is not expected). From the first 
 > view it looks like broken CLI-compatibility...

The manual says:

  A "user-defined command" is a sequence of GDB commands...

GDB command implicitly means CLI command.  I guess an equivalent MI command
could be implemented to execute a sequence of MI commands, but I'm not sure
that it would be needed.

I don't know why you expect "define", a CLI command to accept a list of
MI commands.  Likewise, "source filename" and breakpoint command lists will
only work with CLI commands.

What does seem wrong is that MI no longer works properly with queries:

(gdb) 
-interpreter-exec console "b asdf"
&"Function \"asdf\" not defined.\n"
~"Breakpoint 2 (asdf) pending.\n"
^done
(gdb) 

The user should be asked:

Make breakpoint pending on future shared library load? (y or [n])


Nick

Re: MI usage inside a user-defined commands

[Daniel Jacobowitz]

On Thu, Jul 07, 2005 at 09:26:42AM +1200, Nick Roberts wrote:
> What does seem wrong is that MI no longer works properly with queries:
> 
> (gdb) 
> -interpreter-exec console "b asdf"
> &"Function \"asdf\" not defined.\n"
> ~"Breakpoint 2 (asdf) pending.\n"
> ^done
> (gdb) 
> 
> The user should be asked:
> 
> Make breakpoint pending on future shared library load? (y or [n])

Yes, that does seem like a bug - but how would you perform the query?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Queries in MI [was Re: MI usage inside a user-defined commands]

[Nick Roberts]

 > > The user should be asked:
 > > 
 > > Make breakpoint pending on future shared library load? (y or [n])
 > 
 > Yes, that does seem like a bug - but how would you perform the query?

On older versions of GDB (example slightly changed because -interpreter-exec
and pending breakpoints didn't exist):

(gdb) 
quit
&"quit\n"
~"The program is running.  Exit anyway? (y or n) "
n
&"Not confirmed.\n"
^error,msg="Not confirmed."
(gdb) 

which worked as for CLI.  However, presumably this operation is synchronous.
If MI becomes properly asynchronous then I'm not sure how to do it.  Perhaps
the the frontend could prepend a token on the input, just as MI already uses
tokens for output.

Nick

Re: Queries in MI [was Re: MI usage inside a user-defined commands]

[Daniel Jacobowitz]

On Thu, Jul 07, 2005 at 10:51:50AM +1200, Nick Roberts wrote:
>  > > The user should be asked:
>  > > 
>  > > Make breakpoint pending on future shared library load? (y or [n])
>  > 
>  > Yes, that does seem like a bug - but how would you perform the query?
> 
> On older versions of GDB (example slightly changed because -interpreter-exec
> and pending breakpoints didn't exist):
> 
> (gdb) 
> quit
> &"quit\n"
> ~"The program is running.  Exit anyway? (y or n) "
> n
> &"Not confirmed.\n"
> ^error,msg="Not confirmed."
> (gdb) 
> 
> which worked as for CLI.  However, presumably this operation is synchronous.
> If MI becomes properly asynchronous then I'm not sure how to do it.  Perhaps
> the the frontend could prepend a token on the input, just as MI already uses
> tokens for output.

I don't know that the MI will ever become _that_ asynchronous - GDB is
single threaded, after all.

But, the above isn't particularly warmth-inducing either.  Or
documented, AFAICT.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Queries in MI [was Re: MI usage inside a user-defined commands]

[Bob Rossi]

On Thu, Jul 07, 2005 at 10:51:50AM +1200, Nick Roberts wrote:
>  > > The user should be asked:
>  > > 
>  > > Make breakpoint pending on future shared library load? (y or [n])
>  > 
>  > Yes, that does seem like a bug - but how would you perform the query?
> 
> On older versions of GDB (example slightly changed because -interpreter-exec
> and pending breakpoints didn't exist):
> 
> (gdb) 
> quit
> &"quit\n"
> ~"The program is running.  Exit anyway? (y or n) "
> n
> &"Not confirmed.\n"
> ^error,msg="Not confirmed."
> (gdb) 
> 
> which worked as for CLI.  However, presumably this operation is synchronous.
> If MI becomes properly asynchronous then I'm not sure how to do it.  Perhaps
> the the frontend could prepend a token on the input, just as MI already uses
> tokens for output.

Is it possible that FE's would want to automate the response to a query?
If so, does it make sense to put the query in the MI protocol?

For instance, a FE could implement a way to allow users to set a
breakpoint in the source window by class name/function. Then, when the
FE tries to automate the command, GDB could respond with a query,
the FE could present the user with choices (in dialog) and then send the 
response back. 

With the current response, the FE has no way of doing this.

Bob Rossi

Re: Queries in MI

[Nick Roberts]

 > > If MI becomes properly asynchronous then I'm not sure how to do it.
 > > Perhaps the the frontend could prepend a token on the input, just as MI
 > > already uses tokens for output.
 > 
 > Is it possible that FE's would want to automate the response to a query?
 > If so, does it make sense to put the query in the MI protocol?
 > 
 > For instance, a FE could implement a way to allow users to set a
 > breakpoint in the source window by class name/function. Then, when the
 > FE tries to automate the command, GDB could respond with a query,
 > the FE could present the user with choices (in dialog) and then send the 
 > response back. 
 > 
 > With the current response, the FE has no way of doing this.

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"

I guess the choices for the query could be presented as a dialog box but I
don't know how that changes things.

Perhap, if as Daiel suggests, after a query GDB will only accept the response
to that query, the old behaviour can be re-instated.

Nick

Re: Queries in MI

[Bob Rossi]

On Thu, Jul 07, 2005 at 12:34:29PM +1200, Nick Roberts wrote:
>  > > If MI becomes properly asynchronous then I'm not sure how to do it.
>  > > Perhaps the the frontend could prepend a token on the input, just as MI
>  > > already uses tokens for output.
>  > 
>  > Is it possible that FE's would want to automate the response to a query?
>  > If so, does it make sense to put the query in the MI protocol?
>  > 
>  > For instance, a FE could implement a way to allow users to set a
>  > breakpoint in the source window by class name/function. Then, when the
>  > FE tries to automate the command, GDB could respond with a query,
>  > the FE could present the user with choices (in dialog) and then send the 
>  > response back. 
>  > 
>  > With the current response, the FE has no way of doing this.
> 
> 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
...

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.

Bob Rossi

Re: Queries in MI

[Nick Roberts]

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

Re: MI usage inside a user-defined commands

[Bob Rossi]

On Thu, Jul 07, 2005 at 09:26:42AM +1200, Nick Roberts wrote:
> 
>  > I mean the "define" feature itself works fine under MI (that is expected), 
>  > but allows only CLI commands inside (that is not expected). From the first 
>  > view it looks like broken CLI-compatibility...
> 
> The manual says:
> 
>   A "user-defined command" is a sequence of GDB commands...
> 
> GDB command implicitly means CLI command.  I guess an equivalent MI command
> could be implemented to execute a sequence of MI commands, but I'm not sure
> that it would be needed.
> 
> I don't know why you expect "define", a CLI command to accept a list of
> MI commands.  Likewise, "source filename" and breakpoint command lists will
> only work with CLI commands.
> 
> What does seem wrong is that MI no longer works properly with queries:
> 
> (gdb) 
> -interpreter-exec console "b asdf"
> &"Function \"asdf\" not defined.\n"
> ~"Breakpoint 2 (asdf) pending.\n"
> ^done
> (gdb) 

I've noticed this. I was going to fix it if I had some time.
It won't work when with overloaded function breakpoints either.

Bob Rossi

Re: Queries in MI

[Jim Ingham]

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.

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
>

RE: Queries in MI

[Alain Magloire]

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

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