From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8535 invoked by alias); 17 Dec 2007 11:43:12 -0000 Received: (qmail 8526 invoked by uid 22791); 17 Dec 2007 11:43:12 -0000 X-Spam-Check-By: sourceware.org Received: from smtp1-g19.free.fr (HELO smtp1-g19.free.fr) (212.27.42.27) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 17 Dec 2007 11:43:03 +0000 Received: from smtp1-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp1-g19.free.fr (Postfix) with ESMTP id E377A1AB2B2; Mon, 17 Dec 2007 12:43:00 +0100 (CET) Received: from coin.localdomain (torimasen.com [82.237.12.13]) by smtp1-g19.free.fr (Postfix) with ESMTP id BDFB21AB2A9; Mon, 17 Dec 2007 12:43:00 +0100 (CET) Received: by coin.localdomain (Postfix, from userid 1000) id 8B6DA7A400; Mon, 17 Dec 2007 12:43:00 +0100 (CET) Date: Mon, 17 Dec 2007 11:43:00 -0000 From: Dodji Seketeli To: Nick Roberts Cc: dodji@seketeli.org, gdb@sourceware.org Subject: Re: bug in mi when setting breakpoint Message-ID: <20071217114300.GC4094@coin> Reply-To: dodji@seketeli.org References: <20071216125625.GE4783@coin> <18277.36237.521792.245470@kahikatea.snap.net.nz> <20071217093000.GA4094@coin> <18278.22461.132427.492561@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18278.22461.132427.492561@kahikatea.snap.net.nz> X-Operating-System: GNU/Linux User-Agent: Mutt 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/msg00117.txt.bz2 On Tue, Dec 18, 2007 at 12:04:29AM +1300, Nick Roberts wrote: [...] > > > > I am not aware of the exact changeset that changed the behaviour. Could you > > point me to it please ? I am only aware of what is in gdb 6.7.1 now, sorry. > > I think it's this one: > > 2007-01-03 Jan Kratochvil > Daniel Jacobowitz > > * Makefile.in (top.o): Update. > * top.c (gdb_readline_wrapper_done, gdb_readline_wrapper_result) > (saved_after_char_processing_hook, gdb_readline_wrapper_line) > (struct gdb_readline_wrapper_cleanup, gdb_readline_wrapper_cleanup): > New. > (gdb_readline_wrapper): Rewrite to use asynchronous readline. > > I see behaviour changed around that time. Ah okay Nick. This is really valuable info. Thank you. [...] > > > > So in short, MI disallows prompts. It does this by setting the member > > prompt_proc_p of the struct interp_procs to a function that always returns > > 0. This is done in _initialize_mi_interp() (in gdb/mi/mi-interp.c). > > Why does MI disallow prompts? Presumably it's for good reason and perhaps > you're trying to subvert that. The function gdb_readline_wrapper used to > be just that: a wrapper for readline. It didn't used to do things like > call display_gdb_prompt. Perhaps its name should be changed. I am not sure why MI disallows prompts. But I would think it is because MI has its own prompt, which is the string "(gdb)", and which should appear at the very end of the MI output. So allowing prompt spitted of other parts of the code could possibly break the MI output format. I guess Daniel or Jan could shed some light on this matter ? [...] > > > > I am not sure to understand why are saying this here :-) > > But for what it is worth, the CLI interpreter allows prompt, yes. I am not > > sure to understand why it is unfortunatel > > I'm trying to say that sub-prompts are really for the command line. Ah, okay. > > > > > > > Perhaps, for now, GDB could do something similar, i.e., set all the breakpoints > > > in the breakpoint menu. > > > > Hmmh, no. I think it is important to stay consistent with the format of the > > "question" asked to the user in the pre 6.7.1 and make that question be > > followed by a prompt. Otherwise this would break existing front ends. > > It's probably important not to break existing use, if possible, but you > appear to be parsing CLI output that hasn't really been designed for use > with front ends. So I don't think it's a question of being consistent. Well, all the good graphical debuggers out there let the user choose between function overloads when the user sets a breakpoint by specifier a function name. So there must be a way to let the user choose. I tried to parse the sub-prompt *MI* was spitting because I had not other choice but parse the only thing the mi interpreter was outputing, even if that output was not compliant with the documented MI format. And all the front ends willing to provide that user experience are forced to do the same. So the consistency is maybe not a requirement, but I think it would be really nice to have it. Cheers, -- Dodji Seketeli http://www.seketeli.org/dodji