From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13899 invoked by alias); 4 Jun 2008 11:49:33 -0000 Received: (qmail 13887 invoked by uid 22791); 4 Jun 2008 11:49:32 -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; Wed, 04 Jun 2008 11:49:13 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1K3rUL-0002EB-8J for gdb-patches@sources.redhat.com; Wed, 04 Jun 2008 11:49:09 +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 ; Wed, 04 Jun 2008 11:49:09 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Jun 2008 11:49:09 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: [RFC] 07/10 non-stop inferior control Date: Wed, 04 Jun 2008 11:49:00 -0000 Message-ID: References: <200805061649.24082.pedro@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8Bit User-Agent: KNode/0.10.9 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00021.txt.bz2 Pedro Alves wrote: > This patch adds the inferior control support for non-stop mode. > > In non-stop mode, each thread is handled individually. It should > be like you have a separate debugger attached to each thread. > To accomplish that, as soon as we have an event, we context switch > to it, and go on handling it. The cases of hiting a breakpoint > in another thread while we're stepping don't need to be handled > specially, as the stepping thread will have its state, and the > other thread will have its own state. > > Every exec command should apply only to the selected thread. > > A new target_stop_ptid method was added to request the target > to interrupt a single thread. > > Several checks have been added so GDB doesn't try to do > things with running threads, which don't make sense, > like asking for the current PC of a running thread. > > Info threads now shows the running state of a thread. MI > support can be added on top. > > (gdb) info threads > 3 Thread 0xf7603b90 (LWP 23454)  (running) > * 2 Thread 0xf7e04b90 (LWP 23453)  0xffffe410 in __kernel_vsyscall () > 1 Thread 0xf7e056b0 (LWP 23450)  (running) Am I missing something, or there's no way to interrupt all threads? Given that we have "continue -a"/"-exec-continue --all", I think a way to interrupt all threads will be desirable. In fact, I'd claim that if MI frontend has to issue several -exec-interrupt commands to stop the program completely, it's a regression in functionality. Of course, I can make MI do anything, but I need backend support for that :-) Also, it seems inconsistent to me that "continue" has the -a option, to resume all threads, while "interrupt" accepts an thread id. I'd suggest that "interrupt" be modified to accept -a, and not accept thread number. Or, alternatively, both continue and interrupt accept both -a and thread number. - Volodya