From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32417 invoked by alias); 24 Mar 2008 15:37:34 -0000 Received: (qmail 32405 invoked by uid 22791); 24 Mar 2008 15:37:33 -0000 X-Spam-Check-By: sourceware.org Received: from mail.windriver.com (HELO mail.wrs.com) (147.11.1.11) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 24 Mar 2008 15:36:50 +0000 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m2OFamwB029532 for ; Mon, 24 Mar 2008 08:36:48 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Mar 2008 08:36:47 -0700 Received: from [147.11.233.149] ([147.11.233.149]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Mar 2008 08:36:47 -0700 Message-ID: <47E7CA7B.2080309@windriver.com> Date: Mon, 24 Mar 2008 17:22:00 -0000 From: Pawel Piech User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: Re: MI non-stop mode spec References: <200803190016.02072.vladimir@codesourcery.com> <47E3FA92.40409@windriver.com> <18405.59380.664535.643670@kahikatea.snap.net.nz> In-Reply-To: <18405.59380.664535.643670@kahikatea.snap.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00204.txt.bz2 Hi Nick, Thank you for the reply. I'm still rather curious what you, Vladimir, and anyone else think of the rest of my suggestions. Nick Roberts wrote: > > 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. > I think it would be a great disservice to GDB to disable the console. Even though the console in the IDE is pretty broken for the reasons you mention, a lot of our Eclipse users still value it greatly, so fixing it's interaction with MI would actually be very good for GDB. > 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 Thank you for the explanation. I agree. Currently MI lacks out of band notifications for thread state changes (it has a running event only), thread lifecycle events, memory changed events, registers changed events, modules changed events, and as you mention above breakpoints changed events. Like I said, I'm not familiar with GDB internals, but since CLI has notifications for most of these I can't imagine it would be that hard to add them to MI. One note about the =breakpoints-changed proposed above. I think it would be a mistake to just replace the ^done reply to -break-insert/-break-remove with an event alone, because a client would have no way of knowing whether an event was in response to that client's request or another client's request. I.e. a client would not be able to positively determine the ID of the breakpoint he just created. I see two equally good ways to address this: 1) Add the =breakpoints-changed event in addition to the ^done with breakpoint info, but the =breakpoints-changed would have to be sent AFTER the ^done reply. 2) Allow clients to specify their own arbitrary ID for a breakpoint, with an option such as -client-id="abc". Then have the =breakpoints-changed event and other query commands echo the client-id along with the regular breakpoint ID. Cheers, Pawel