From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18887 invoked by alias); 16 Dec 2007 20:42:04 -0000 Received: (qmail 18879 invoked by uid 22791); 16 Dec 2007 20:42:04 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 16 Dec 2007 20:41:56 +0000 Received: from kahikatea.snap.net.nz (90.60.255.123.dynamic.snap.net.nz [123.255.60.90]) by viper.snap.net.nz (Postfix) with ESMTP id 7446C3D9CFB; Mon, 17 Dec 2007 09:41:53 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id E15EF8FC6D; Mon, 17 Dec 2007 09:41:50 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18277.36237.521792.245470@kahikatea.snap.net.nz> Date: Sun, 16 Dec 2007 20:42:00 -0000 To: dodji@seketeli.org Cc: gdb@sourceware.org Subject: Re: bug in mi when setting breakpoint In-Reply-To: <20071216125625.GE4783@coin> References: <20071216125625.GE4783@coin> X-Mailer: VM 7.19 under Emacs 23.0.50.12 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00109.txt.bz2 > In that case, the breakpoint setting code > asks the user to choose the overloaded function it wants to break in. > To do so, the breakpoint setting code displays something like: > > ~"[0] cancel\n[1] all\n" > ~"[2] classname::function_name(int) at fooprog.cc:65\n" > ~"[3] classname::function_name() at fooprog.cc:59\n" > ~"> " > > The last line of this "question" is the default prompt indicating the end > of the question. > > In gdb 6.7.1, that prompt is missing *only* when using the MI interpreter. > It is present in the CLI interpreter. And this is a regression from 6.6 > where the prompt was present with both interpreters. Your patch appears to introduce new behaviour. The question to ask is what change broke this behaviour? I suspect it was the change to readline made at the start to this year. GDB seems to go into gdb_readline_wrapper from decode_line_2 and stay there. > The prompt is really important for graphical front-end tools willing > to parse that "question" so that they can display display it > back to the user in a nice windowed manner. > As the question does not really respect the GDB/MI output format where the > output should be ended by a "(gdb)" string, the prompt is the only way th > front end can detect the end of the "question". > > So I tried to produce the attached patch to pinpoint the problem and > hopefully propose a fix. Unfortunately CLI also uses sub-prompts for several other commands: queries e.g pending breakpoints, exiting after exevution has started; the "commands" command. I don't think that they fit well with the MI paradigm: MI expects MI output. With queries, GDB takes affirmative action, e.g., creates pending breakpoints regardless of the value of "show breakpoint pending" and exits regardless of the value of "show confirm". Perhaps, for now, GDB could do something similar, i.e., set all the breakpoints in the breakpoint menu. -- Nick http://www.inet.net.nz/~nickrob