Re: GDB/MI interactive capability?

[Joel Brobecker <brobecker at adacore dot com>]

> 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