From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126347 invoked by alias); 29 Apr 2015 15:30:57 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 126333 invoked by uid 89); 29 Apr 2015 15:30:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 29 Apr 2015 15:30:56 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 0D5F8D3C72; Wed, 29 Apr 2015 11:30:54 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kh3MiJ8HjAjr; Wed, 29 Apr 2015 11:30:53 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id E6693D36D6; Wed, 29 Apr 2015 11:30:53 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id E098D40EAD; Wed, 29 Apr 2015 11:30:53 -0400 (EDT) Date: Wed, 29 Apr 2015 15:44:00 -0000 From: Joel Brobecker To: Vladimir Prus Cc: gdb-patches@sourceware.org Subject: Re: GDB/MI interactive capability? Message-ID: <20150429153053.GD4994@adacore.com> References: <20150422192522.GM4764@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-04/txt/msg01070.txt.bz2 > 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(&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