From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66214 invoked by alias); 29 Apr 2015 19:16:43 -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 66204 invoked by uid 89); 29 Apr 2015 19:16:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-la0-f45.google.com Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com) (209.85.215.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 29 Apr 2015 19:16:41 +0000 Received: by layy10 with SMTP id y10so27808425lay.0 for ; Wed, 29 Apr 2015 12:16:37 -0700 (PDT) X-Received: by 10.112.146.97 with SMTP id tb1mr561017lbb.12.1430334997640; Wed, 29 Apr 2015 12:16:37 -0700 (PDT) Received: from [192.168.0.111] (h86-62-88-129.ln.rinet.ru. [86.62.88.129]) by mx.google.com with ESMTPSA id uj9sm6583795lbb.38.2015.04.29.12.16.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 12:16:36 -0700 (PDT) Message-ID: <55412E27.1060004@gmail.com> Date: Wed, 29 Apr 2015 19:40:00 -0000 From: Vladimir Prus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 Newsgroups: gmane.comp.gdb.patches To: Joel Brobecker CC: gdb-patches@sourceware.org Subject: Re: GDB/MI interactive capability? References: <20150422192522.GM4764@adacore.com> <20150429153053.GD4994@adacore.com> In-Reply-To: <20150429153053.GD4994@adacore.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-04/txt/msg01084.txt.bz2 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(&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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66939 invoked by alias); 29 Apr 2015 19:16:55 -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 66929 invoked by uid 89); 29 Apr 2015 19:16:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: plane.gmane.org Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 29 Apr 2015 19:16:47 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YnXTP-0001tk-Ck for gdb-patches@sourceware.org; Wed, 29 Apr 2015 21:16:43 +0200 Received: from h86-62-88-129.ln.rinet.ru ([86.62.88.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Apr 2015 21:16:43 +0200 Received: from vladimir.prus by h86-62-88-129.ln.rinet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Apr 2015 21:16:43 +0200 To: gdb-patches@sourceware.org From: Vladimir Prus Subject: Re: GDB/MI interactive capability? Date: Wed, 29 Apr 2015 20:30:00 -0000 Message-ID: <55412E27.1060004@gmail.com> References: <20150422192522.GM4764@adacore.com> <20150429153053.GD4994@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: gdb-patches@sourceware.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 In-Reply-To: <20150429153053.GD4994@adacore.com> X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg01085.txt.bz2 Message-ID: <20150429203000.3cmgaiZMcshGuL-713nGXiNM7fD1rUoJfvrR8e01PLU@z> 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(&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