From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20976 invoked by alias); 12 May 2009 15:58:08 -0000 Received: (qmail 20965 invoked by uid 22791); 12 May 2009 15:58:05 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 May 2009 15:58:01 +0000 Received: (qmail 830 invoked from network); 12 May 2009 15:57:59 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 May 2009 15:57:59 -0000 From: Pedro Alves To: "Marc Khouzam" Subject: Re: Does HEAD support non-stop with 'gdbserver --multi' on Linux? Date: Tue, 12 May 2009 15:58:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb@sourceware.org References: <6D19CA8D71C89C43A057926FE0D4ADAA075CAD65@ecamlmw720.eamcs.ericsson.se> <6D19CA8D71C89C43A057926FE0D4ADAA075CB54C@ecamlmw720.eamcs.ericsson.se> <6D19CA8D71C89C43A057926FE0D4ADAA076CB70C@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA076CB70C@ecamlmw720.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905121658.05954.pedro@codesourcery.com> 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: 2009-05/txt/msg00067.txt.bz2 On Tuesday 12 May 2009 16:21:48, Marc Khouzam wrote: > I saw that with non-stop, when doing native linux debugging, there > is a conscious decision to trigger thread events as soon as possible > (from a comment of linux-nat.c:linux_handle_extended_wait()). At the time I added that to linux-nat.c it seemed like a good idea, but in hindsight, I'm not sure it was. This has the potential to generate *a lot* of create/exit event pairs for no apparent good reason --- consider a program that spawns a lot of short lived worker threads. Against remote targets, this would be even worse, due to extra slowness. > However, this does not happen when using gdbserver. > > Is this something that is not ready yet, or a bug, or ... ? This is a remote protocol issue. The remote protocol does not have any support for new thread notifications. GDB only learns about new threads when they report an event (say one hits a breakpoints), or when the thread list is explicitly requested. OOC, how does the eclipse/java debugger behave on such scenario? Are short lived threads added/removed from the GUI even if they don't report a stop event? -- Pedro Alves