From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9451 invoked by alias); 16 Dec 2007 21:21:11 -0000 Received: (qmail 9434 invoked by uid 22791); 16 Dec 2007 21:21:08 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 16 Dec 2007 21:20:24 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J40uF-0001CC-LX for gdb@sources.redhat.com; Sun, 16 Dec 2007 21:20:15 +0000 Received: from 77.246.241.246 ([77.246.241.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Dec 2007 21:20:15 +0000 Received: from ghost by 77.246.241.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Dec 2007 21:20:15 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: bug in mi when setting breakpoint Date: Sun, 16 Dec 2007 21:21:00 -0000 Message-ID: References: <20071216125625.GE4783@coin> <18277.36237.521792.245470@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.4 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/msg00110.txt.bz2 Nick Roberts wrote: > > 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" I don't think that's true. Week old CVS HEAD won't ever create pending breakpoint when using MI. Today's CVS HEAD will create pending breakpoint if you use the -f option to -break-insert. Without that option, pending breakpoint won't ever be created. > 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. In general, I think that any command that requires any interactivity should explicitly document how it would handle that. - Volodya