From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20855 invoked by alias); 27 Mar 2008 06:41:52 -0000 Received: (qmail 20707 invoked by uid 22791); 27 Mar 2008 06:41:51 -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; Thu, 27 Mar 2008 06:41:31 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Jelnh-0006l1-94 for gdb@sources.redhat.com; Thu, 27 Mar 2008 06:41:25 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Mar 2008 06:41:25 +0000 Received: from ghost by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Mar 2008 06:41:25 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: MI non-stop mode spec Date: Thu, 27 Mar 2008 14:13:00 -0000 Message-ID: References: <200803190016.02072.vladimir@codesourcery.com> <47E3FA92.40409@windriver.com> <200803242016.19140.vladimir@codesourcery.com> <47E7F4D4.9050501@windriver.com> <47E81C22.4000508@windriver.com> <47E93A59.7020400@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/msg00261.txt.bz2 Pawel Piech wrote: > Vladimir Prus wrote: >>> >>> Thanks for agreeing :-) Like I said, I have no idea of the complexity >>> of such a change. However, it seems to me that you should be able to >>> implement a simple protcol-state-tracking logic for both CLI and MI >>> protocols, and simply simulate the --thread option for commands that >>> don't supply one. This way you could have both the backward compatible >>> stateful protocol, and have the -thread option to override it on the >>> individual commands. >>> >> >> This might be actually a reasonable thing. On one thing, not switching >> the current thread might be good for CLI. On the other hand, I still believe >> that --thread is ultimately better solution for MI. Then, it might be best to >> make GDB not to switch threads (benefiting CLI and stateful MI), and >> also accept --thread for the benefit of newer MI clients. >> >> Now there's the catch that --thread is already implemented and is rather >> straightforward, whereas I expect some corner cases in implementing thread >> that does not change. I think we'll first get the non-stop mode working >> with --thread, and then look into making current thread not change. >> (For avoidance of doubt, "then" means "immediately after" not "someday"). >> > > I think this would be an excellent compromise. If there is any kind of > a layering between the protocol interpreter and the underlying > functions, it shouldn't be too much of a stretch to add the state > tracking in the protocol interpreter layer. This is one implementation approach -- add current thread in MI, and switch GDB's global current thread to MI's current thread when executing any command. This is not very hard, but won't help CLI. Another approach is to do the same trick for CLI. Yet another approach is to make sure GDB never changes its global thread except internally, when it's guaranteed not to talk to user. We'll see which approach is best. > BTW, for the clients that > support both a UI and a command console it would be even even better if > CLI and MI maintained their own current thread and stack frame. This > would prevent the two interfaces from interfering with each other. Oh, that's interesting idea. But, would it not be confusing if frontend shows certain thread and frame as current in UI, whereas commands in GDB console operate on some other thread? - Volodya