From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27018 invoked by alias); 24 Mar 2008 17:22:58 -0000 Received: (qmail 27009 invoked by uid 22791); 24 Mar 2008 17:22:57 -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; Mon, 24 Mar 2008 17:22:31 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JdqNL-0005Ob-SF for gdb@sources.redhat.com; Mon, 24 Mar 2008 17:22:23 +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 ; Mon, 24 Mar 2008 17:22:23 +0000 Received: from ghost by 77.246.241.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Mar 2008 17:22:23 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: MI non-stop mode spec Date: Mon, 24 Mar 2008 20:23:00 -0000 Message-ID: References: <200803190016.02072.vladimir@codesourcery.com> <47E3FA92.40409@windriver.com> <18405.59380.664535.643670@kahikatea.snap.net.nz> <47E7CA7B.2080309@windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.5 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/msg00206.txt.bz2 Pawel Piech wrote: >> 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, Oh, I think that last one might be tricky to implement :-) > 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, It's not being proposed. Per my spec, each MI command results in one of ^done, ^error, ^connected or ^running to be output. > 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. We probably can suppress =breakpoints-changed for the -break-insert command. - Volodya