This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB/MI interactive capability?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]