Re: GDB/MI interactive capability?

[Vladimir Prus <vladimir.prus@gmail.com>]

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