From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17758 invoked by alias); 12 May 2009 16:23:39 -0000 Received: (qmail 17750 invoked by uid 22791); 12 May 2009 16:23:38 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 May 2009 16:23:30 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n4CGXiSY029548; Tue, 12 May 2009 11:33:47 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 May 2009 11:23:05 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Does HEAD support non-stop with 'gdbserver --multi' on Linux? Date: Tue, 12 May 2009 16:23:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA076CB802@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <200905121658.05954.pedro@codesourcery.com> References: <6D19CA8D71C89C43A057926FE0D4ADAA075CAD65@ecamlmw720.eamcs.ericsson.se> <6D19CA8D71C89C43A057926FE0D4ADAA075CB54C@ecamlmw720.eamcs.ericsson.se> <6D19CA8D71C89C43A057926FE0D4ADAA076CB70C@ecamlmw720.eamcs.ericsson.se> <200905121658.05954.pedro@codesourcery.com> From: "Marc Khouzam" To: "Pedro Alves" Cc: 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/msg00068.txt.bz2 > -----Original Message----- > From: gdb-owner@sourceware.org=20 > [mailto:gdb-owner@sourceware.org] On Behalf Of Pedro Alves > Sent: Tuesday, May 12, 2009 11:58 AM > To: Marc Khouzam > Cc: gdb@sourceware.org > Subject: Re: Does HEAD support non-stop with 'gdbserver=20 > --multi' on Linux? >=20 > 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()). >=20 > 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. Yes, this was bothering me too, from the frontend point-of-view. >=20 > > However, this does not happen when using gdbserver. > >=20 > > Is this something that is not ready yet, or a bug, or ... ? >=20 > 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. >=20 > 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? Good question. I just ran some test to figure this out. It turns out that threads are added and removed from the GUI without any stop event. Furthermore, was creating and destroying a thread every 200 milisec, and the UI was flickering to show each=20 and every change! But that may not be the way we want to go... I'm not sure. This behavior could be a user preference. Right now, in DSF-GDB for GDB7.0, any =3Dthread-created/exited event will immediately be shown to the user. I was postponing addressing this risk until someone brought this up as a problem... Currently, I'm leaning towards a periodic refresh scheme. Say every half second, the list of threads would be refreshed if needed. But I have to think about this further. Such a scheme could be used in GDB also. Marc =20