GDB/MI interactive capability?

GDB/MI interactive capability?

[Joel Brobecker]

Vladimir, All,

A question that I was asked by the IDE Team at AdaCore, who is trying
to transition to using GDB/MI instead of CLI + annotations.

Consider a program where we have multiple functions having the same
name (In our case "foo"). In CLI mode, evaluating an expression
referencing one of those functions results in a multiple-choice menu
being printed, asking for the user to select the one he meant us
to call. Eg:

    (gdb) p foo(null)
    Multiple matches for foo
    [0] cancel
    [1] foo.foo at foo.adb:9
    [2] foo.foo at foo.adb:19

Ideally, we'd like to have the same behavior when using the GDB/MI
protocol, and be able to query the user. Do you think we could enhance
the protocol that way?

For instance ("->" means we send to GDB, and "<-" means we receive
from GDB):

-> -data-evaluate-expression foo(null)

<- ^user-input-needed,id=NNN,choices=[
        {number=0, description='cancel'},
        {number=1, description='foo.foo at foo.adb:9'},
        {number=2, description='foo.foo at foo.adb:19}]

The id=NNN would just be a way to identify each user query, and
would be used to identify which query the user's answer is for.
We'd answer the query as follow:

-> -user-input NNNN  ANSWER
<- ^done,[as usual]

This is just thinking out loud. I'm not even sure whether it'll be
all that easy to implement this idea, especially if we want GDB to
remain responsive (Eg, to perform other operations and therefore
send other GDB/MI commands) while waiting for the user's answer.

Another idea, which might be easier to implement, would be to use
a two-step approach where the first step is to return an error
that shows the various choices the user can choose, have the IDE
use that to query the user, and then have the IDE resubmit the
expression evaluation, this time with the choice given by the user.

WDYT?

-- 
Joel

Re: GDB/MI interactive capability?

[Vladimir Prus]

Hi Joel,

On 04/22/2015 10:25 PM, Joel Brobecker wrote:
> Vladimir, All,
>
> A question that I was asked by the IDE Team at AdaCore, who is trying
> to transition to using GDB/MI instead of CLI + annotations.
>
> Consider a program where we have multiple functions having the same
> name (In our case "foo"). In CLI mode, evaluating an expression
> referencing one of those functions results in a multiple-choice menu
> being printed, asking for the user to select the one he meant us
> to call. Eg:
>
>      (gdb) p foo(null)
>      Multiple matches for foo
>      [0] cancel
>      [1] foo.foo at foo.adb:9
>      [2] foo.foo at foo.adb:19
>
> Ideally, we'd like to have the same behavior when using the GDB/MI
> protocol, and be able to query the user. Do you think we could enhance
> the protocol that way?
>
> For instance ("->" means we send to GDB, and "<-" means we receive
> from GDB):
>
> -> -data-evaluate-expression foo(null)
>
> <- ^user-input-needed,id=NNN,choices=[
>          {number=0, description='cancel'},
>          {number=1, description='foo.foo at foo.adb:9'},
>          {number=2, description='foo.foo at foo.adb:19}]
>
> The id=NNN would just be a way to identify each user query, and
> would be used to identify which query the user's answer is for.
> We'd answer the query as follow:
>
> -> -user-input NNNN  ANSWER
> <- ^done,[as usual]
>
> This is just thinking out loud. I'm not even sure whether it'll be
> all that easy to implement this idea, especially if we want GDB to
> remain responsive (Eg, to perform other operations and therefore
> send other GDB/MI commands) while waiting for the user's answer.

I think a bigger problem is that it will make the MI protocol itself stateful.
Right now, we have GDB and program state, of course, but each MI command is
generally independent of any other one. The above proposal will basically
create interdependencies between MI commands.

> Another idea, which might be easier to implement, would be to use
> a two-step approach where the first step is to return an error
> that shows the various choices the user can choose, have the IDE
> use that to query the user, and then have the IDE resubmit the
> expression evaluation, this time with the choice given by the user.

That would work just fine, I think. GDB can report the ambiguities it finds,
and the frontend can resubmit the expression with appropriate syntax to disambiguate.
I don't know whether there's appropriate syntax for Ada, in C++ a cast to appropriate
type is sometimes used to select the right function, e.g.:

	static_cast<void (C::*)(int)>(&C::foo)

is the standard example. The downside is that GDB might have to know a bit more about
language than now, or a special syntax might have to be introduced.


-- 
Vladimir Prus
CodeSourcery / Mentor Embedded
http://vladimirprus.com

Re: GDB/MI interactive capability?

[Matt Rice]

On Sun, Apr 26, 2015 at 11:40 AM, Vladimir Prus <vladimir.prus@gmail.com> wrote:
> On 04/22/2015 10:25 PM, Joel Brobecker wrote:

>> Another idea, which might be easier to implement, would be to use
>> a two-step approach where the first step is to return an error
>> that shows the various choices the user can choose, have the IDE
>> use that to query the user, and then have the IDE resubmit the
>> expression evaluation, this time with the choice given by the user.
>
>
> That would work just fine, I think. GDB can report the ambiguities it finds,
> and the frontend can resubmit the expression with appropriate syntax to
> disambiguate.
> I don't know whether there's appropriate syntax for Ada, in C++ a cast to
> appropriate
> type is sometimes used to select the right function, e.g.:
>
>         static_cast<void (C::*)(int)>(&C::foo)
>
> is the standard example. The downside is that GDB might have to know a bit
> more about
> language than now, or a special syntax might have to be introduced.

I think it might work that instead of sending a list of stateful
numbers, it instead sent a list of explicit linespecs that can be sent
back to gdb
I'm not entirely sure (but it seems reasonable) that explicit
linespecs might avoid the ambiguity of sending a linespec to the
client which can lead to things like PR 8535

Re: GDB/MI interactive capability?

[Joel Brobecker]

> I think a bigger problem is that it will make the MI protocol itself stateful.
> Right now, we have GDB and program state, of course, but each MI command is
> generally independent of any other one. The above proposal will basically
> create interdependencies between MI commands.

OK, makes sense.

> >Another idea, which might be easier to implement, would be to use
> >a two-step approach where the first step is to return an error
> >that shows the various choices the user can choose, have the IDE
> >use that to query the user, and then have the IDE resubmit the
> >expression evaluation, this time with the choice given by the user.
> 
> That would work just fine, I think. GDB can report the ambiguities it
> finds, and the frontend can resubmit the expression with appropriate
> syntax to disambiguate.  I don't know whether there's appropriate
> syntax for Ada, in C++ a cast to appropriate type is sometimes used to
> select the right function, e.g.:
> 
> 	static_cast<void (C::*)(int)>(&C::foo)
> 
> is the standard example. The downside is that GDB might have to know a
> bit more about language than now, or a special syntax might have to be
> introduced.

It wouldn't work in GDB, because overload resolution is extremely
complex, and not something we want to implement in GDB. Right now,
we have a primitive resolver, doing the easiest part of the resolution,
but nothing more.

So, I think having a way to just pass the answer back to the query
would be the way to go. And it'd be more general in case we want
to ask other things that are not related to symbol resolution.

Thanks!
-- 
Joel

Re: GDB/MI interactive capability?

[Vladimir Prus]

On 04/29/2015 06:30 PM, Joel Brobecker wrote:
>> I think a bigger problem is that it will make the MI protocol itself stateful.
>> Right now, we have GDB and program state, of course, but each MI command is
>> generally independent of any other one. The above proposal will basically
>> create interdependencies between MI commands.
>
> OK, makes sense.
>
>>> Another idea, which might be easier to implement, would be to use
>>> a two-step approach where the first step is to return an error
>>> that shows the various choices the user can choose, have the IDE
>>> use that to query the user, and then have the IDE resubmit the
>>> expression evaluation, this time with the choice given by the user.
>>
>> That would work just fine, I think. GDB can report the ambiguities it
>> finds, and the frontend can resubmit the expression with appropriate
>> syntax to disambiguate.  I don't know whether there's appropriate
>> syntax for Ada, in C++ a cast to appropriate type is sometimes used to
>> select the right function, e.g.:
>>
>> 	static_cast<void (C::*)(int)>(&C::foo)
>>
>> is the standard example. The downside is that GDB might have to know a
>> bit more about language than now, or a special syntax might have to be
>> introduced.
>
> It wouldn't work in GDB, because overload resolution is extremely
> complex, and not something we want to implement in GDB. Right now,
> we have a primitive resolver, doing the easiest part of the resolution,
> but nothing more.

I don't think the above requires overload resolution, it requires that GDB pick a member
function whose signature exactly matches the cast destination type, which should be quite
possible. I can't really think of an example where ambiguity cannot be resolved by
language expression - except for function templates, but GDB can't do much with them
anyway. But see below.

> So, I think having a way to just pass the answer back to the query
> would be the way to go. And it'd be more general in case we want
> to ask other things that are not related to symbol resolution.

True, passing responses to queries via an option is a more general solution. Also,
it means that frontend does not have to know how to transform expression to disambiguate
things - it can just pass the responses.


-- 
Vladimir Prus
CodeSourcery / Mentor Embedded
http://vladimirprus.com

Re: GDB/MI interactive capability?

[Vladimir Prus]

On 04/29/2015 06:30 PM, Joel Brobecker wrote:
>> I think a bigger problem is that it will make the MI protocol itself stateful.
>> Right now, we have GDB and program state, of course, but each MI command is
>> generally independent of any other one. The above proposal will basically
>> create interdependencies between MI commands.
>
> OK, makes sense.
>
>>> Another idea, which might be easier to implement, would be to use
>>> a two-step approach where the first step is to return an error
>>> that shows the various choices the user can choose, have the IDE
>>> use that to query the user, and then have the IDE resubmit the
>>> expression evaluation, this time with the choice given by the user.
>>
>> That would work just fine, I think. GDB can report the ambiguities it
>> finds, and the frontend can resubmit the expression with appropriate
>> syntax to disambiguate.  I don't know whether there's appropriate
>> syntax for Ada, in C++ a cast to appropriate type is sometimes used to
>> select the right function, e.g.:
>>
>> 	static_cast<void (C::*)(int)>(&C::foo)
>>
>> is the standard example. The downside is that GDB might have to know a
>> bit more about language than now, or a special syntax might have to be
>> introduced.
>
> It wouldn't work in GDB, because overload resolution is extremely
> complex, and not something we want to implement in GDB. Right now,
> we have a primitive resolver, doing the easiest part of the resolution,
> but nothing more.

I don't think the above requires overload resolution, it requires that GDB pick a member
function whose signature exactly matches the cast destination type, which should be quite
possible. I can't really think of an example where ambiguity cannot be resolved by
language expression - except for function templates, but GDB can't do much with them
anyway. But see below.

> So, I think having a way to just pass the answer back to the query
> would be the way to go. And it'd be more general in case we want
> to ask other things that are not related to symbol resolution.

True, passing responses to queries via an option is a more general solution. Also,
it means that frontend does not have to know how to transform expression to disambiguate
things - it can just pass the responses.


-- 
Vladimir Prus
CodeSourcery / Mentor Embedded
http://vladimirprus.com