From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21280 invoked by alias); 23 Mar 2008 05:18:27 -0000 Received: (qmail 21269 invoked by uid 22791); 23 Mar 2008 05:18:27 -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, 23 Mar 2008 05:17:50 +0000 Received: from kahikatea.snap.net.nz (165.60.255.123.dynamic.snap.net.nz [123.255.60.165]) by viper.snap.net.nz (Postfix) with ESMTP id D74D53DA2B8; Sun, 23 Mar 2008 18:17:42 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 54AEF8FC6D; Sun, 23 Mar 2008 17:17:41 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18405.59380.664535.643670@kahikatea.snap.net.nz> Date: Mon, 24 Mar 2008 04:03:00 -0000 To: Pawel Piech Cc: Vladimir Prus , gdb@sources.redhat.com Subject: Re: MI non-stop mode spec In-Reply-To: <47E3FA92.40409@windriver.com> References: <200803190016.02072.vladimir@codesourcery.com> <47E3FA92.40409@windriver.com> X-Mailer: VM 7.19 under Emacs 22.1.92.2 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: 2008-03/txt/msg00196.txt.bz2 > I don't fully understand why disabling CLI commands is desired, but I'm > guessing it's because the CLI commands would still rely on the current > thread. If so, then keeping the MI protocol stateful would hopefully > address that concern and not force you to disable the CLI interface, > which would be unfortunate. It's probably not desired but it's certainly more effort. Perhaps the customer in question can be persuaded of it's value: it's certainly important for any frontend that wants to keep the console. This still provides access to a lot of funtionality in GDB that hasn't yet been properly implemented in MI. Currently commands like -break-insert gives synchronous MI output for the frontend to parse while the CLI command "break" issued under MI, "-interpreter-exec console break", say, just gives CLI output. I think this is the wrong approach and that -break-insert shouldn't generate the output directly but instead MI should generate event notifications informing the frontend of changes: =breakpoints-changed,... This could be done with observers like Vladimir has done for threads and would produce the same notifications regardless of whether the breakpoint was created with a CLI or MI command. Likewise with the new commands for non-stop mode. -- Nick http://www.inet.net.nz/~nickrob