From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26925 invoked by alias); 7 Jul 2005 18:10:15 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 26911 invoked by uid 22791); 7 Jul 2005 18:10:11 -0000 Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 07 Jul 2005 18:10:11 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j67IA9kv029077 for ; Thu, 7 Jul 2005 11:10:09 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 7 Jul 2005 11:10:08 -0700 Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id j67IA7NL014654 for ; Thu, 7 Jul 2005 11:10:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <1120724185.29158.ezmlm@sources.redhat.com> References: <1120724185.29158.ezmlm@sources.redhat.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <299DE329-298E-4020-A349-CA4C510970EF@apple.com> Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: Queries in MI Date: Thu, 07 Jul 2005 18:10:00 -0000 To: gdb@sources.redhat.com X-SW-Source: 2005-07/txt/msg00070.txt.bz2 Seems to me like the need for query responses from the Front End comes in two categories. One is things that are predictable, like the question "do you want to set undefined breakpoints". Or when you re-run with the executable still running and gdb asks whether you want to terminate the target. In these cases, the MI command should be crafted to allow the FE to select one choice or the other, and the default should be something reasonable. There's no reason to support a query here, the FE should be able to figure out what it wants in advance and just do it. The other is when the Front End can't a priori know enough to make a decision. The only example we've come across so far is with breakpoints that resolve to multiple choices. In that case, what we do is we don't set any breakpoints, but return a list of choices to the UI instead. Then I've tarted up the -break-insert so that it will take a selection list as well, and if the selection list is there, it will choose those options from the list. What we did is a little weak in that I don't verify that the breakpoint expression you send back with the selection list is the same as the one you sent when I generated the list. But that was complicated to do, and I was pretty sure we could trust the FE not to willfully shoot itself in the foot here... This way, we don't have to keep stateful interactions suspended between the UI & the FE, which seemed a more robust design to me. I don't think I see any cases of queries that can't be handled this way. Of course, you have to make sure that commands issued with "- interpreter-exec console" return the queries to the console properly, that's a separate issue. That works in our gdb, but I don't remember whether Keith, Elena et al merged all this stuff over or not. Jim On Jul 7, 2005, at 1:16 AM, gdb-digest-help@sources.redhat.com wrote: > > > >>> I'm not sure what you're suggesting, but Emacs will always want >>> to allow >>> CLI input through the GUD buffer which, for example, will be >>> forwarded to >>> GDB as: >>> >>> -interpreter-exec console "b asdf" >>> >> >> Of course. Your stating the case when the user sends a command to GDB >> and get's a query as a response. That's fine. >> >> What about the case when the FE sends a command to GDB and has to >> deal >> with the query? That isn't capable with the current output. The MI >> response would have to have the query information built into it, >> like, >> >> -break-insert "b asdf" >> ^done,query={choice1="...",choice2="..."} >> FE sends->choice1 >> ... >> > > Well "b asdf" is a CLI command, but I take your point. Currently, > if asdf is > symbol that is in a shared library that is yet to be loaded, then > > (gdb) > -break-insert asdf > &"Function \"asdf\" not defined.\n" > ^done > (gdb) > > This is the opposite behaviour to -interpreter-exec console "b asdf" > and the same as you would you would get using CLI with "set confirm > off". > > >> I currently don't have a need for such a feature, but I'm just >> suggesting that the current mechanism doesn't allow the FE to do this >> sort of thing nicely. I'm sure it will be needed eventually. >> > > You're suggesting a syntax. I'm not sure what the mechanism should > be, > because if GDB is made to wait for a response that might break other > things. > > Nick >