From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22153 invoked by alias); 8 Jul 2005 17:39:53 -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 22111 invoked by uid 22791); 8 Jul 2005 17:39:45 -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; Fri, 08 Jul 2005 17:39:45 +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 j68HdhHl022121 for ; Fri, 8 Jul 2005 10:39:43 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Fri, 8 Jul 2005 10:39:43 -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 j68HdfHJ025433; Fri, 8 Jul 2005 10:39:41 -0700 (PDT) In-Reply-To: <1578FF984ABAD411AFA5000102C4BB5B115961DA@NIMBUS> References: <1578FF984ABAD411AFA5000102C4BB5B115961DA@NIMBUS> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: gdb@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: Queries in MI Date: Fri, 08 Jul 2005 17:39:00 -0000 To: Alain Magloire X-SW-Source: 2005-07/txt/msg00088.txt.bz2 Oops, I beg your pardon. Apparently we didn't implement this for query. The area we did implement user input for was the "command" and "define" commands. I don't remember now why we didn't use the same mechanism for query, it would have been easy to do that... Anyway, for "command" it looks something like: -> 81-interpreter-exec console-quoted "commands 1" <- (gdb) <- =read-one-line,prompt=">" -> print self <- =read-one-line,prompt=">" -> end <- 81^done,time= {wallclock="7.87027",user="0.00050",system="0.00040",start="1120843556.1 42967",end="1120843564.013233"} This is the log format that Xcode spits out. The lines with the -> are commands sent to gdb. The lines with the <- lines sent back to Xcode. The request for a line of input is an asynchronous message from gdb, which seems correct to me. We do this by hooking into the "command_line_input hook". I don't remember now why we didn't do the same thing for the query_hook. Probably we just forgot. Jim On Jul 8, 2005, at 9:36 AM, Alain Magloire wrote: > > > >> -----Original Message----- >> From: gdb-owner@sources.redhat.com [mailto:gdb- >> owner@sources.redhat.com] >> On Behalf Of Jim Ingham >> Sent: Thursday, July 07, 2005 2:10 PM >> To: gdb@sources.redhat.com >> Subject: Re: Queries in MI >> >> 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. >> >> > > Good question... > But it this case what we ending doing is check for the prompt(the > secondary > prompt, usually ">") and allow the user to finish by entering commands > Without any interpretation. This very weak and prone to since for that > case we our at the mercy of the user to finish the sequence, any other > Command form the FE will interfere with this. > It would be nice for the next version of MI to handle this a little > more > Elegantly. Based on you experience with MI did you have any > thoughts ? > > >> 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 >>> >