MI query questions

MI query questions

[Bob Rossi]

Hi all,

I was looking at what else I need in MI working before I have a minimal
FE working properly. This is one area of concern to me.

This is from the console:

    (gdb) b A::func
    [0] cancel
    [1] all
    [2] A::func(float) at overloaded.cpp:8
    [3] A::func(int) at overloaded.cpp:7
    > q
    Arguments must be choice numbers.
    (gdb) q

This is from MI interp:
    (gdb)
    -break-insert A::func
    ~"[0] cancel\n[1] all\n"
    ~"[2] A::func(float) at overloaded.cpp:8\n"
    ~"[3] A::func(int) at overloaded.cpp:7\n"
    >

The first small issue is that the '[1] all\n' choice is on the same
line as the [0] choice. This may not be a problem at all, I'm not sure.
It looks as if this case would still output properly on the FE's console
window.

The second issue is how GDB outputs a final ">" line. This isn't a valid
GDB/MI Output record/command. At least, I don't think it is. If I select
an option, then I get this

> 1
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x08048381",func="A::func(float)",file="overloaded.cpp",fullname="/home/bob/rcs/svn/cgdb/cgdb.mi/cgdb/tgdb/testsuite/tgdb.base/overloaded.cpp",line="8",times="0"},bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x0804837b",func="A::func(int)",file="overloaded.cpp",fullname="/home/bob/rcs/svn/cgdb/cgdb.mi/cgdb/tgdb/testsuite/tgdb.base/overloaded.cpp",line="7",times="0"}
(gdb)

Which looks pretty good to me. So the problem is, the line ">"
apparently means to get input from the user. This isn't specified in the
MI OUTPUT record. Should we change the OUTPUT record to represent
interactive commands?

Has someone else already thought about a good way to handle this?

Thanks,
Bob Rossi

Re: MI query questions

[Daniel Jacobowitz]

On Mon, May 29, 2006 at 08:23:37AM -0400, Bob Rossi wrote:
> The first small issue is that the '[1] all\n' choice is on the same
> line as the [0] choice.

That's because the ~"" blocks come from individual calls to printf.

> The second issue is how GDB outputs a final ">" line. This isn't a valid
> GDB/MI Output record/command. At least, I don't think it is. If I select
> an option, then I get this

> Which looks pretty good to me. So the problem is, the line ">"
> apparently means to get input from the user. This isn't specified in the
> MI OUTPUT record. Should we change the OUTPUT record to represent
> interactive commands?

I don't really think we should shoehorn these queries into MI.  It
would make more sense to me to have it do something MI-like.  For
example, not set any breakpoint, but return a more exact list of places
the breakpoint could be placed.  If you want the query behavior, you
could of course use interpreter-exec :-)

I dunno what that new response would look like, and I'm not especially
interested in working it out; just sharing my opinion.  The > bit is
very un-MI, and e.g. it prevents pipelining MI commands.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI query questions

[Jim Ingham]

What we did for this is along the lines Daniel suggested.  When we  
find multiple matches to a breakpoint, we return "matches", and then  
a list of matches, something like:

^done,matches={b={index="0",canonical="-[NSException raise]",binary="/ 
System/Library/Frameworks/Foundation.framework/Versions/C/ 
Foundation",line="0",addr="0x9294d008"},b= 
{index="1",canonical="raise",binary="/usr/lib/ 
libSystem.B.dylib",line="0",addr="0x9012f940"}}

Then you have to provide some way for the UI to turn around and set  
the breakpoints it wants to set.  You aren't really guaranteed that  
the UI will know how to cons up a breakpoint expression that will  
return the breakpoint you want.  We tried using the canonical form,  
and with that and the shared library you could do it mostly, except  
if we start doing things like template breakpoints.  So we added a -l  
option to -break-insert that takes a list of the indices and sets the  
breakpoints for that list.

It might have been cleaner to tie the list to the original -break- 
insert command, like having -break-insert pass back a cookie along  
with the matches, and then do:

-break-confirm <cookie> <list>

But I wanted to keep it stateless to make the implementation in gdb  
simpler.  So the UI just sends the -break-insert twice, the second  
time with the list.  You can also send "-1" for the list, and we will  
automatically accept all the breakpoints.

Jim


On May 29, 2006, at 7:46 AM, Daniel Jacobowitz wrote:

> On Mon, May 29, 2006 at 08:23:37AM -0400, Bob Rossi wrote:
>> The first small issue is that the '[1] all\n' choice is on the same
>> line as the [0] choice.
>
> That's because the ~"" blocks come from individual calls to printf.
>
>> The second issue is how GDB outputs a final ">" line. This isn't a  
>> valid
>> GDB/MI Output record/command. At least, I don't think it is. If I  
>> select
>> an option, then I get this
>
>> Which looks pretty good to me. So the problem is, the line ">"
>> apparently means to get input from the user. This isn't specified  
>> in the
>> MI OUTPUT record. Should we change the OUTPUT record to represent
>> interactive commands?
>
> I don't really think we should shoehorn these queries into MI.  It
> would make more sense to me to have it do something MI-like.  For
> example, not set any breakpoint, but return a more exact list of  
> places
> the breakpoint could be placed.  If you want the query behavior, you
> could of course use interpreter-exec :-)
>
> I dunno what that new response would look like, and I'm not especially
> interested in working it out; just sharing my opinion.  The > bit is
> very un-MI, and e.g. it prevents pipelining MI commands.
>
> -- 
> Daniel Jacobowitz
> CodeSourcery

Re: MI query questions

[Bob Rossi]

On Tue, May 30, 2006 at 09:59:55AM -0700, Jim Ingham wrote:
> What we did for this is along the lines Daniel suggested.  When we  
> find multiple matches to a breakpoint, we return "matches", and then  
> a list of matches, something like:
> 
> ^done,matches={b={index="0",canonical="-[NSException raise]",binary="/ 
> System/Library/Frameworks/Foundation.framework/Versions/C/ 
> Foundation",line="0",addr="0x9294d008"},b= 
> {index="1",canonical="raise",binary="/usr/lib/ 
> libSystem.B.dylib",line="0",addr="0x9012f940"}}
> 
> Then you have to provide some way for the UI to turn around and set  
> the breakpoints it wants to set.  You aren't really guaranteed that  
> the UI will know how to cons up a breakpoint expression that will  
> return the breakpoint you want.  We tried using the canonical form,  
> and with that and the shared library you could do it mostly, except  
> if we start doing things like template breakpoints.  So we added a -l  
> option to -break-insert that takes a list of the indices and sets the  
> breakpoints for that list.
> 
> It might have been cleaner to tie the list to the original -break- 
> insert command, like having -break-insert pass back a cookie along  
> with the matches, and then do:
> 
> -break-confirm <cookie> <list>
> 
> But I wanted to keep it stateless to make the implementation in gdb  
> simpler.  So the UI just sends the -break-insert twice, the second  
> time with the list.  You can also send "-1" for the list, and we will  
> automatically accept all the breakpoints.

What about the -interpreter-exec console "b A::func" case?

Thanks,
Bob Rossi

Re: MI query questions

[Jim Ingham]

For that we added a "command_line_input_hook" which we run at the  
beginning of command_line_input in top.c.  We have an "mi running  
cli" version that we put in place when we run -interpreter-exec.   
This hook sends an async message like:

(gdb) set interpreter mi1
-interpreter-exec console "break raise"
[0] cancel
[1] all

Non-debugging symbols:
[2]    -[NSException raise]
[3]    raise
=read-one-line,prompt="> "

When the UI gets this, it can put up the prompt, and then send the  
next line of input when it gets one.  You have to do this not only  
for the break command, but also so things like:

-interpreter-exec console "define foo"

and

-interpreter-exec console "commands $bpnum"

work properly.

Looks like the hooks are all gone away from TOT gdb.  I'm not sure  
what is supposed to replace them in instances like this.  But anyway,  
something like this is what you will probably want to do.

Jim

On May 30, 2006, at 10:15 AM, Bob Rossi wrote:

> On Tue, May 30, 2006 at 09:59:55AM -0700, Jim Ingham wrote:
>> What we did for this is along the lines Daniel suggested.  When we
>> find multiple matches to a breakpoint, we return "matches", and then
>> a list of matches, something like:
>>
>> ^done,matches={b={index="0",canonical="-[NSException  
>> raise]",binary="/
>> System/Library/Frameworks/Foundation.framework/Versions/C/
>> Foundation",line="0",addr="0x9294d008"},b=
>> {index="1",canonical="raise",binary="/usr/lib/
>> libSystem.B.dylib",line="0",addr="0x9012f940"}}
>>
>> Then you have to provide some way for the UI to turn around and set
>> the breakpoints it wants to set.  You aren't really guaranteed that
>> the UI will know how to cons up a breakpoint expression that will
>> return the breakpoint you want.  We tried using the canonical form,
>> and with that and the shared library you could do it mostly, except
>> if we start doing things like template breakpoints.  So we added a -l
>> option to -break-insert that takes a list of the indices and sets the
>> breakpoints for that list.
>>
>> It might have been cleaner to tie the list to the original -break-
>> insert command, like having -break-insert pass back a cookie along
>> with the matches, and then do:
>>
>> -break-confirm <cookie> <list>
>>
>> But I wanted to keep it stateless to make the implementation in gdb
>> simpler.  So the UI just sends the -break-insert twice, the second
>> time with the list.  You can also send "-1" for the list, and we will
>> automatically accept all the breakpoints.
>
> What about the -interpreter-exec console "b A::func" case?
>
> Thanks,
> Bob Rossi

Re: MI query questions

[Jim Ingham]

Actually, to avoid confusion, this really looks like:

(gdb) set interpreter mi1
-interpreter-exec console-quoted "break raise"
~"[0] cancel\n[1] all\n"
~"\nNon-debugging symbols:\n"
~"[2]    -[NSException raise]\n"
~"[3]    raise\n"
=read-one-line,prompt="> "

In our version of gdb the console interpreter really is the straight  
CLI console interpreter - this is required to get the "set  
interpreter" command to work.  So we had to invent another  
interpreter that did the proper quoting.  Anyway, this is what it  
would look like for you...

Jim

On May 30, 2006, at 10:41 AM, Jim Ingham wrote:

> For that we added a "command_line_input_hook" which we run at the  
> beginning of command_line_input in top.c.  We have an "mi running  
> cli" version that we put in place when we run -interpreter-exec.   
> This hook sends an async message like:
>
> (gdb) set interpreter mi1
> -interpreter-exec console "break raise"
> [0] cancel
> [1] all
>
> Non-debugging symbols:
> [2]    -[NSException raise]
> [3]    raise
> =read-one-line,prompt="> "
>
> When the UI gets this, it can put up the prompt, and then send the  
> next line of input when it gets one.  You have to do this not only  
> for the break command, but also so things like:
>
> -interpreter-exec console "define foo"
>
> and
>
> -interpreter-exec console "commands $bpnum"
>
> work properly.
>
> Looks like the hooks are all gone away from TOT gdb.  I'm not sure  
> what is supposed to replace them in instances like this.  But  
> anyway, something like this is what you will probably want to do.
>
> Jim
>
> On May 30, 2006, at 10:15 AM, Bob Rossi wrote:
>
>> On Tue, May 30, 2006 at 09:59:55AM -0700, Jim Ingham wrote:
>>> What we did for this is along the lines Daniel suggested.  When we
>>> find multiple matches to a breakpoint, we return "matches", and then
>>> a list of matches, something like:
>>>
>>> ^done,matches={b={index="0",canonical="-[NSException  
>>> raise]",binary="/
>>> System/Library/Frameworks/Foundation.framework/Versions/C/
>>> Foundation",line="0",addr="0x9294d008"},b=
>>> {index="1",canonical="raise",binary="/usr/lib/
>>> libSystem.B.dylib",line="0",addr="0x9012f940"}}
>>>
>>> Then you have to provide some way for the UI to turn around and set
>>> the breakpoints it wants to set.  You aren't really guaranteed that
>>> the UI will know how to cons up a breakpoint expression that will
>>> return the breakpoint you want.  We tried using the canonical form,
>>> and with that and the shared library you could do it mostly, except
>>> if we start doing things like template breakpoints.  So we added  
>>> a -l
>>> option to -break-insert that takes a list of the indices and sets  
>>> the
>>> breakpoints for that list.
>>>
>>> It might have been cleaner to tie the list to the original -break-
>>> insert command, like having -break-insert pass back a cookie along
>>> with the matches, and then do:
>>>
>>> -break-confirm <cookie> <list>
>>>
>>> But I wanted to keep it stateless to make the implementation in gdb
>>> simpler.  So the UI just sends the -break-insert twice, the second
>>> time with the list.  You can also send "-1" for the list, and we  
>>> will
>>> automatically accept all the breakpoints.
>>
>> What about the -interpreter-exec console "b A::func" case?
>>
>> Thanks,
>> Bob Rossi
>

Re: MI query questions

[Bob Rossi]

On Tue, May 30, 2006 at 10:48:53AM -0700, Jim Ingham wrote:
> Actually, to avoid confusion, this really looks like:
> 
> (gdb) set interpreter mi1
> -interpreter-exec console-quoted "break raise"
> ~"[0] cancel\n[1] all\n"
> ~"\nNon-debugging symbols:\n"
> ~"[2]    -[NSException raise]\n"
> ~"[3]    raise\n"
> =read-one-line,prompt="> "
> 
> In our version of gdb the console interpreter really is the straight  
> CLI console interpreter - this is required to get the "set  
> interpreter" command to work.  So we had to invent another  
> interpreter that did the proper quoting.  Anyway, this is what it  
> would look like for you...

This is also the solution I was thinking of. However, I would like to
modify the MI OUTPUT record to show this as a possibility. Also, I think
that this should be 1 full response.
    (gdb) set interpreter mi1
    -interpreter-exec console-quoted "break raise"
    ~"[0] cancel\n[1] all\n"
    ~"\nNon-debugging symbols:\n"
    ~"[2]    -[NSException raise]\n"
    ~"[3]    raise\n"
    =read-one-line,prompt="> "
    (gdb)

And then the user will send the command, and then get another full
response representing the breakpoint output.

Does this make sense?

This would mean that there would be a new part of the MI output record
that would tell the FE that it needs to ask the user for more
information. Most FE's that have used annotate 1 or 2 have already come
across this situation and dealt with it nicely.

Thanks,
Bob Rossi

Re: MI query questions

[Daniel Jacobowitz]

On Tue, May 30, 2006 at 01:53:10PM -0400, Bob Rossi wrote:
> This is also the solution I was thinking of. However, I would like to
> modify the MI OUTPUT record to show this as a possibility. Also, I think
> that this should be 1 full response.
>     (gdb) set interpreter mi1
>     -interpreter-exec console-quoted "break raise"
>     ~"[0] cancel\n[1] all\n"
>     ~"\nNon-debugging symbols:\n"
>     ~"[2]    -[NSException raise]\n"
>     ~"[3]    raise\n"
>     =read-one-line,prompt="> "
>     (gdb)
> 
> And then the user will send the command, and then get another full
> response representing the breakpoint output.
> 
> Does this make sense?

I don't think so.  The (gdb) marker means you're at an MI prompt.  But
you aren't.  You can't send an arbitrary MI command here.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI query questions

[Jim Ingham]

On May 30, 2006, at 10:53 AM, Bob Rossi wrote:

> On Tue, May 30, 2006 at 10:48:53AM -0700, Jim Ingham wrote:
>> Actually, to avoid confusion, this really looks like:
>>
>> (gdb) set interpreter mi1
>> -interpreter-exec console-quoted "break raise"
>> ~"[0] cancel\n[1] all\n"
>> ~"\nNon-debugging symbols:\n"
>> ~"[2]    -[NSException raise]\n"
>> ~"[3]    raise\n"
>> =read-one-line,prompt="> "
>>
>> In our version of gdb the console interpreter really is the straight
>> CLI console interpreter - this is required to get the "set
>> interpreter" command to work.  So we had to invent another
>> interpreter that did the proper quoting.  Anyway, this is what it
>> would look like for you...
>
> This is also the solution I was thinking of. However, I would like to
> modify the MI OUTPUT record to show this as a possibility. Also, I  
> think
> that this should be 1 full response.
>     (gdb) set interpreter mi1
>     -interpreter-exec console-quoted "break raise"
>     ~"[0] cancel\n[1] all\n"
>     ~"\nNon-debugging symbols:\n"
>     ~"[2]    -[NSException raise]\n"
>     ~"[3]    raise\n"
>     =read-one-line,prompt="> "
>     (gdb)
>
> And then the user will send the command, and then get another full
> response representing the breakpoint output.
>
> Does this make sense?

I'm not sure I like this.  It doesn't really seem to mirror what's  
going on.  The -interpreter-exec command hasn't finished, rather,  
it's asking - out of band - for some more information.  So sending an  
out-of-band message with this request seems cleaner.  Why do you want  
the extra (gdb) prompt?

Jim

>
> This would mean that there would be a new part of the MI output record
> that would tell the FE that it needs to ask the user for more
> information. Most FE's that have used annotate 1 or 2 have already  
> come
> across this situation and dealt with it nicely.
>
> Thanks,
> Bob Rossi

Re: MI query questions

[Bob Rossi]

On Tue, May 30, 2006 at 10:59:38AM -0700, Jim Ingham wrote:
> 
> On May 30, 2006, at 10:53 AM, Bob Rossi wrote:
> 
> >On Tue, May 30, 2006 at 10:48:53AM -0700, Jim Ingham wrote:
> >>Actually, to avoid confusion, this really looks like:
> >>
> >>(gdb) set interpreter mi1
> >>-interpreter-exec console-quoted "break raise"
> >>~"[0] cancel\n[1] all\n"
> >>~"\nNon-debugging symbols:\n"
> >>~"[2]    -[NSException raise]\n"
> >>~"[3]    raise\n"
> >>=read-one-line,prompt="> "
> >>
> >>In our version of gdb the console interpreter really is the straight
> >>CLI console interpreter - this is required to get the "set
> >>interpreter" command to work.  So we had to invent another
> >>interpreter that did the proper quoting.  Anyway, this is what it
> >>would look like for you...
> >
> >This is also the solution I was thinking of. However, I would like to
> >modify the MI OUTPUT record to show this as a possibility. Also, I  
> >think
> >that this should be 1 full response.
> >    (gdb) set interpreter mi1
> >    -interpreter-exec console-quoted "break raise"
> >    ~"[0] cancel\n[1] all\n"
> >    ~"\nNon-debugging symbols:\n"
> >    ~"[2]    -[NSException raise]\n"
> >    ~"[3]    raise\n"
> >    =read-one-line,prompt="> "
> >    (gdb)
> >
> >And then the user will send the command, and then get another full
> >response representing the breakpoint output.
> >
> >Does this make sense?
> 
> I'm not sure I like this.  It doesn't really seem to mirror what's  
> going on.  The -interpreter-exec command hasn't finished, rather,  
> it's asking - out of band - for some more information.  So sending an  
> out-of-band message with this request seems cleaner.  Why do you want  
> the extra (gdb) prompt?
> 
> Jim

I'm not sure what I asked for makes the most sense. However, I don't
really like what I see above. 

Basically, up until now, the only time a front end would send data is 
at the (gdb) prompt. That's when GDB is ready to except another command.
This is also nice because if the FE generates a parser, it wants to feed
that parser data until it spits out an MI output record. The parser 
eventually spits out another MI outout record, the FE process's it, and 
then sends another command to GDB.

However, in the case above, the parser will keep eating data, and then 
at some point, GDB will stop sending data and the MI output record has
not been completed. This means the parser will have to have some ugly 
callback mechanism saying that the FE should send another command to GDB.

What about something like this:

    (gdb) set interpreter mi1
    -interpreter-exec console-quoted "break raise"
    ~"[0] cancel\n[1] all\n"
    ~"\nNon-debugging symbols:\n"
    ~"[2]    -[NSException raise]\n"
    ~"[3]    raise\n"
    =read-one-line,prompt="> "
    (gdb_oob_query)

I'm just brain storming here. What did you think of my rational?

Bob Rossi

Re: MI query questions

[Jim Ingham]

Seems like having a callback in your parser to handle async messages  
from gdb represents cleanly what is going on.  You haven't gotten a  
completed MI command yet, and you're not ready for another MI  
command.  But gdb is asking on the side for more input.  Seems like  
making the two cases look the same is more likely to cause trouble.

Jim


On May 30, 2006, at 11:11 AM, Bob Rossi wrote:

> On Tue, May 30, 2006 at 10:59:38AM -0700, Jim Ingham wrote:
>>
>> On May 30, 2006, at 10:53 AM, Bob Rossi wrote:
>>
>>> On Tue, May 30, 2006 at 10:48:53AM -0700, Jim Ingham wrote:
>>>> Actually, to avoid confusion, this really looks like:
>>>>
>>>> (gdb) set interpreter mi1
>>>> -interpreter-exec console-quoted "break raise"
>>>> ~"[0] cancel\n[1] all\n"
>>>> ~"\nNon-debugging symbols:\n"
>>>> ~"[2]    -[NSException raise]\n"
>>>> ~"[3]    raise\n"
>>>> =read-one-line,prompt="> "
>>>>
>>>> In our version of gdb the console interpreter really is the  
>>>> straight
>>>> CLI console interpreter - this is required to get the "set
>>>> interpreter" command to work.  So we had to invent another
>>>> interpreter that did the proper quoting.  Anyway, this is what it
>>>> would look like for you...
>>>
>>> This is also the solution I was thinking of. However, I would  
>>> like to
>>> modify the MI OUTPUT record to show this as a possibility. Also, I
>>> think
>>> that this should be 1 full response.
>>>    (gdb) set interpreter mi1
>>>    -interpreter-exec console-quoted "break raise"
>>>    ~"[0] cancel\n[1] all\n"
>>>    ~"\nNon-debugging symbols:\n"
>>>    ~"[2]    -[NSException raise]\n"
>>>    ~"[3]    raise\n"
>>>    =read-one-line,prompt="> "
>>>    (gdb)
>>>
>>> And then the user will send the command, and then get another full
>>> response representing the breakpoint output.
>>>
>>> Does this make sense?
>>
>> I'm not sure I like this.  It doesn't really seem to mirror what's
>> going on.  The -interpreter-exec command hasn't finished, rather,
>> it's asking - out of band - for some more information.  So sending an
>> out-of-band message with this request seems cleaner.  Why do you want
>> the extra (gdb) prompt?
>>
>> Jim
>
> I'm not sure what I asked for makes the most sense. However, I don't
> really like what I see above.
>
> Basically, up until now, the only time a front end would send data is
> at the (gdb) prompt. That's when GDB is ready to except another  
> command.
> This is also nice because if the FE generates a parser, it wants to  
> feed
> that parser data until it spits out an MI output record. The parser
> eventually spits out another MI outout record, the FE process's it,  
> and
> then sends another command to GDB.
>
> However, in the case above, the parser will keep eating data, and then
> at some point, GDB will stop sending data and the MI output record has
> not been completed. This means the parser will have to have some ugly
> callback mechanism saying that the FE should send another command  
> to GDB.
>
> What about something like this:
>
>     (gdb) set interpreter mi1
>     -interpreter-exec console-quoted "break raise"
>     ~"[0] cancel\n[1] all\n"
>     ~"\nNon-debugging symbols:\n"
>     ~"[2]    -[NSException raise]\n"
>     ~"[3]    raise\n"
>     =read-one-line,prompt="> "
>     (gdb_oob_query)
>
> I'm just brain storming here. What did you think of my rational?
>
> Bob Rossi

Re: MI query questions

[Bob Rossi]

On Tue, May 30, 2006 at 11:40:51AM -0700, Jim Ingham wrote:
> Seems like having a callback in your parser to handle async messages  
> from gdb represents cleanly what is going on.  You haven't gotten a  
> completed MI command yet, and you're not ready for another MI  
> command.  But gdb is asking on the side for more input.  Seems like  
> making the two cases look the same is more likely to cause trouble.

I undstand, and sort of agree with you. However, things get slightly
worse from my perspective. I've designed my FE thus far to behave like
this: 
  - It is always looking for data from GDB to assemble MI output records.
  - It will send only a single GDB command at a time.

With that in mind, my FE assembles an MI output record, and then sends
it up the chain to be looked at more specifically. However, with this 
callback-in-the-middle scenario, my FE will have to be retrained to
handle partially returned MI output records.

Does this seem acceptable to you?

For instance, the annotate=2 looks like this:
    pre-prompt
    (gdb)
    prompt
    b A::func

    post-prompt
    [0] cancel
    [1] all
    [2] A::func(float) at overloaded.cpp:8
    [3] A::func(int) at overloaded.cpp:7

    pre-overload-choice
    >
    overload-choice

I think the overload choice is as much a prompt as any other command. I'm
not exactly sure why you think it's a "special" input from the user.

I do see your point about the way your FE does this, however, do you see
my point here?

Thanks,
Bob Rossi

Re: MI query questions

[Jim Ingham]

On May 30, 2006, at 11:54 AM, Bob Rossi wrote:

> On Tue, May 30, 2006 at 11:40:51AM -0700, Jim Ingham wrote:
>> Seems like having a callback in your parser to handle async messages
>> from gdb represents cleanly what is going on.  You haven't gotten a
>> completed MI command yet, and you're not ready for another MI
>> command.  But gdb is asking on the side for more input.  Seems like
>> making the two cases look the same is more likely to cause trouble.
>
> I undstand, and sort of agree with you. However, things get slightly
> worse from my perspective. I've designed my FE thus far to behave like
> this:
>   - It is always looking for data from GDB to assemble MI output  
> records.
>   - It will send only a single GDB command at a time.
>
> With that in mind, my FE assembles an MI output record, and then sends
> it up the chain to be looked at more specifically. However, with this
> callback-in-the-middle scenario, my FE will have to be retrained to
> handle partially returned MI output records.
>
> Does this seem acceptable to you?
>
> For instance, the annotate=2 looks like this:
>     pre-prompt
>     (gdb)
>     prompt
>     b A::func
>
>     post-prompt
>     [0] cancel
>     [1] all
>     [2] A::func(float) at overloaded.cpp:8
>     [3] A::func(int) at overloaded.cpp:7
>
>     pre-overload-choice
>>
>     overload-choice
>
> I think the overload choice is as much a prompt as any other  
> command. I'm
> not exactly sure why you think it's a "special" input from the user.

I thought Daniel already answered this.  It's not prompting for MI  
input, which is what the ordinary prompt does, it's just trying to  
slide some information to the CLI interpreter under the covers.  As  
such it is very different from the ordinary prompt.  You also don't  
have a completed MI output at this point - you haven't seen the  
matching ^done or any other appropriate command terminator - so in  
any case you are going to have to deal with partial MI output.

I also like this =read-one-line thingie, because it makes it explicit  
what's going on, namely something other than the MI is trying to read  
one line of input.  So the FE should solicit a line of input from  
whoever it's getting that from in the command that caused this  
message to be delivered, and send it on...

Jim

>
> I do see your point about the way your FE does this, however, do  
> you see
> my point here?
>
> Thanks,
> Bob Rossi

Re: MI query questions

[Daniel Jacobowitz]

On Tue, May 30, 2006 at 01:14:12PM -0700, Jim Ingham wrote:
> I also like this =read-one-line thingie, because it makes it explicit  
> what's going on, namely something other than the MI is trying to read  
> one line of input.  So the FE should solicit a line of input from  
> whoever it's getting that from in the command that caused this  
> message to be delivered, and send it on...

While I agree at first look, on the other hand:

(A) It messes up pipelining.  You can't throw five commands at GDB at
once, if one of them might eat further input.

(B) It makes parsing the output somewhat trickier.

Would it be helpful to have some general solution for this, presumably
involving completions (i.e. closures)?  Come back and answer the prompt
when you're ready?

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI query questions

[Jim Ingham]

On May 30, 2006, at 1:45 PM, Daniel Jacobowitz wrote:

> On Tue, May 30, 2006 at 01:14:12PM -0700, Jim Ingham wrote:
>> I also like this =read-one-line thingie, because it makes it explicit
>> what's going on, namely something other than the MI is trying to read
>> one line of input.  So the FE should solicit a line of input from
>> whoever it's getting that from in the command that caused this
>> message to be delivered, and send it on...
>
> While I agree at first look, on the other hand:
>
> (A) It messes up pipelining.  You can't throw five commands at GDB at
> once, if one of them might eat further input.

Yes, though another approach is to mark commands that can't safely be  
in the middle of a pipeline - of which there is really just one: - 
interpreter-exec.  Then if you do pipeline those it's your own fault.

After all, I can't think of any case where a real MI command has any  
business prompting for more info, and I don't think we would want to  
make that an available mode for MI commands.  I think for the MI  
itself it's much better to have them do their job atomically...   So  
the issue only arises when you are passing control to another  
interpreter, and waiting till that has given control back before  
issuing more commands seems the safe thing to do.

>
> (B) It makes parsing the output somewhat trickier.
>
> Would it be helpful to have some general solution for this, presumably
> involving completions (i.e. closures)?  Come back and answer the  
> prompt
> when you're ready?

This would probably be nicer, though I'm not sure it's worth the  
effort unless there are other places where we can forsee using this  
beyond -interpreter-exec.

Jim 

Re: MI query questions

[Daniel Jacobowitz]

On Tue, May 30, 2006 at 02:10:46PM -0700, Jim Ingham wrote:
> >(B) It makes parsing the output somewhat trickier.
> >
> >Would it be helpful to have some general solution for this, presumably
> >involving completions (i.e. closures)?  Come back and answer the  
> >prompt
> >when you're ready?
> 
> This would probably be nicer, though I'm not sure it's worth the  
> effort unless there are other places where we can forsee using this  
> beyond -interpreter-exec.

You're right - this is probably the only one.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI query questions

[Bob Rossi]

On Tue, May 30, 2006 at 05:14:55PM -0400, Daniel Jacobowitz wrote:
> On Tue, May 30, 2006 at 02:10:46PM -0700, Jim Ingham wrote:
> > >(B) It makes parsing the output somewhat trickier.
> > >
> > >Would it be helpful to have some general solution for this, presumably
> > >involving completions (i.e. closures)?  Come back and answer the  
> > >prompt
> > >when you're ready?
> > 
> > This would probably be nicer, though I'm not sure it's worth the  
> > effort unless there are other places where we can forsee using this  
> > beyond -interpreter-exec.
> 
> You're right - this is probably the only one.

Hmm, I'm sorry to be the one that doesn't understand whats being said
here. Could someone spell this out for me in simple terms?

Thanks,
Bob Rossi

MI query questions

[Nick Roberts]

 > This is from MI interp:
 >     (gdb)
 >     -break-insert A::func
 >     ~"[0] cancel\n[1] all\n"
 >     ~"[2] A::func(float) at overloaded.cpp:8\n"
 >     ~"[3] A::func(int) at overloaded.cpp:7\n"
 >     >

This isn't really a query in the GDB sense of the word i.e it's not a yes/no
question and it doesn't call the function query.  We've discussed queries in
MI on this mailing list before and the current behaviour is to take a default
value e.g "no" for pending breakpoints.

I suggest, for the moment, at least, that we make MI select "[1] all"
automatically in this case.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI query questions

[Bob Rossi]

On Tue, May 30, 2006 at 03:22:11PM +1200, Nick Roberts wrote:
>  > This is from MI interp:
>  >     (gdb)
>  >     -break-insert A::func
>  >     ~"[0] cancel\n[1] all\n"
>  >     ~"[2] A::func(float) at overloaded.cpp:8\n"
>  >     ~"[3] A::func(int) at overloaded.cpp:7\n"
>  >     >
> 
> This isn't really a query in the GDB sense of the word i.e it's not a yes/no
> question and it doesn't call the function query.  We've discussed queries in
> MI on this mailing list before and the current behaviour is to take a default
> value e.g "no" for pending breakpoints.
> 
> I suggest, for the moment, at least, that we make MI select "[1] all"
> automatically in this case.

Nick,

I don't think this solves the problem though. As Daniel pointed out,

-interpreter-exec console "b A::func"

will cause the same problem, and needs to be addressed. I haven't
thought this through well enough though.

Bob Rossi

Re: MI query questions

[Nick Roberts]

 > > I suggest, for the moment, at least, that we make MI select "[1] all"
 > > automatically in this case.
 > 
 > Nick,
 > 
 > I don't think this solves the problem though. As Daniel pointed out,
 > 
 > -interpreter-exec console "b A::func"
 > 
 > will cause the same problem, and needs to be addressed. I haven't
 > thought this through well enough though.

Well, I guess it depends whether the existing behaviour breaks the front
end or not i.e when the prompt ">" appears will it know that GDB wants
more input or not?  If the answer is yes (I've not tried it) then things
can be left as they are.  If its no, then something should be done and the
solution being proposed doesn't sound like a quick fix.

"-interpreter-exec console "b A::func" could presumably be made to behave
as "-break-insert A::func".  Witness pending breakpoints:

(gdb)
-break-insert fgfg
&"Function \"fgfg\" not defined.\n"
^done
(gdb)
-interpreter-exec console "b ghgh"
&"Function \"ghgh\" not defined.\n"
~"Breakpoint 1 (ghgh) pending.\n"
^done
(gdb)
inf bre
&"inf bre\n"
~"Num Type           Disp Enb Address    What\n"
~"1   breakpoint     keep y   <PENDING>  ghgh\n"
^done
(gdb)

For the CLI command "break" the behaviour seems to be reversed but it's
no longer a query.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI query questions

[Bob Rossi]

On Wed, May 31, 2006 at 09:30:00AM +1200, Nick Roberts wrote:
>  > > I suggest, for the moment, at least, that we make MI select "[1] all"
>  > > automatically in this case.
>  > 
>  > Nick,
>  > 
>  > I don't think this solves the problem though. As Daniel pointed out,
>  > 
>  > -interpreter-exec console "b A::func"
>  > 
>  > will cause the same problem, and needs to be addressed. I haven't
>  > thought this through well enough though.
> 
> Well, I guess it depends whether the existing behaviour breaks the front
> end or not i.e when the prompt ">" appears will it know that GDB wants
> more input or not?  If the answer is yes (I've not tried it) then things
> can be left as they are.  If its no, then something should be done and the
> solution being proposed doesn't sound like a quick fix.
> 
> "-interpreter-exec console "b A::func" could presumably be made to behave
> as "-break-insert A::func".  Witness pending breakpoints:

I wouldn't like to change the behavior of the CLI commands. This would
be confusing to users and I don't think they would like it at all.

> (gdb)
> -break-insert fgfg
> &"Function \"fgfg\" not defined.\n"
> ^done
> (gdb)
> -interpreter-exec console "b ghgh"
> &"Function \"ghgh\" not defined.\n"
> ~"Breakpoint 1 (ghgh) pending.\n"
> ^done
> (gdb)
> inf bre
> &"inf bre\n"
> ~"Num Type           Disp Enb Address    What\n"
> ~"1   breakpoint     keep y   <PENDING>  ghgh\n"
> ^done
> (gdb)
> 
> For the CLI command "break" the behaviour seems to be reversed but it's
> no longer a query.

I think this is a bug in GDB that there is no longer a query. The user
is going to want to know why they are not prompted when using the FE,
but they are prompted when using GDB. I think this is a step backwards,
not forwards.

Bob Rossi

Re: MI query questions

[Nick Roberts]

 > >  > > I suggest, for the moment, at least, that we make MI select "[1] all"
 > >  > > automatically in this case.
 > >  > 
 > >  > Nick,
 > >  > 
 > >  > I don't think this solves the problem though. As Daniel pointed out,
 > >  > 
 > >  > -interpreter-exec console "b A::func"
 > >  > 
 > >  > will cause the same problem, and needs to be addressed. I haven't
 > >  > thought this through well enough though.
 > > 
 > > Well, I guess it depends whether the existing behaviour breaks the front
 > > end or not i.e when the prompt ">" appears will it know that GDB wants
 > > more input or not?  If the answer is yes (I've not tried it) then things
 > > can be left as they are.  If its no, then something should be done and the
 > > solution being proposed doesn't sound like a quick fix.
 > > 
 > > "-interpreter-exec console "b A::func" could presumably be made to behave
 > > as "-break-insert A::func".  Witness pending breakpoints:
 > 
 > I wouldn't like to change the behavior of the CLI commands. This would
 > be confusing to users and I don't think they would like it at all.

I don't know how it would work to keep existing CLI behaviour.  I think
"-interpreter-exec console" only works for single isolated CLI commands and
not for ones like "source", "commands", "if", "while" etc or user-defined
ones.  Current behaviour seems to be broken, I'm just trying to suggest an
immediate temporary fix.  Will your solution be ready for 6.5?

 > > (gdb)
 > > -break-insert fgfg
 > > &"Function \"fgfg\" not defined.\n"
 > > ^done
 > > (gdb)
 > > -interpreter-exec console "b ghgh"
 > > &"Function \"ghgh\" not defined.\n"
 > > ~"Breakpoint 1 (ghgh) pending.\n"
 > > ^done
 > > (gdb)
 > > inf bre
 > > &"inf bre\n"
 > > ~"Num Type           Disp Enb Address    What\n"
 > > ~"1   breakpoint     keep y   <PENDING>  ghgh\n"
 > > ^done
 > > (gdb)
 > > 
 > > For the CLI command "break" the behaviour seems to be reversed but it's
 > > no longer a query.
 > 
 > I think this is a bug in GDB that there is no longer a query. The user
 > is going to want to know why they are not prompted when using the FE,
 > but they are prompted when using GDB. I think this is a step backwards,
 > not forwards.

We've had this one before. With "b ghgh", deprecated_query_hook has the value 
mi_interp_query_hook which always returns 1, so this is deliberate.  With
"-break-insert fgfg" the error `Function "fgfg" not defined.' is caught further
up the stack and GDB never gets a chance to set the breakpoint.  I don't
know if that's deliberate.

-- 
Nick                                           http://www.inet.net.nz/~nickrob