From: Vladimir Prus <vladimir.prus@gmail.com>
To: gdb-patches@sourceware.org
Cc: gdb-patches@sourceware.org
Subject: Re: GDB/MI interactive capability?
Date: Wed, 29 Apr 2015 20:30:00 -0000 [thread overview]
Message-ID: <55412E27.1060004@gmail.com> (raw)
Message-ID: <20150429203000.3cmgaiZMcshGuL-713nGXiNM7fD1rUoJfvrR8e01PLU@z> (raw)
In-Reply-To: <20150429153053.GD4994@adacore.com>
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
next prev parent reply other threads:[~2015-04-29 19:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-22 19:25 Joel Brobecker
2015-04-26 18:45 ` Vladimir Prus
2015-04-27 3:28 ` Matt Rice
2015-04-29 15:44 ` Joel Brobecker
2015-04-29 19:40 ` Vladimir Prus [this message]
2015-04-29 20:30 ` Vladimir Prus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55412E27.1060004@gmail.com \
--to=vladimir.prus@gmail.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).