From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7050 invoked by alias); 1 Dec 2007 01:43:43 -0000 Received: (qmail 7042 invoked by uid 22791); 1 Dec 2007 01:43:42 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 01 Dec 2007 01:43:36 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 1C1DA3BED1; Fri, 30 Nov 2007 17:43:34 -0800 (PST) Subject: Re: Keeping breakpoints inserted From: Michael Snyder To: Jim Blandy Cc: Thiago Jung Bauermann , Vladimir Prus , gdb@sources.redhat.com In-Reply-To: References: <200711292224.23659.vladimir@codesourcery.com> <1196456622.6746.169.camel@localhost.localdomain> <1196458063.2501.153.camel@localhost.localdomain> Content-Type: text/plain Date: Sat, 01 Dec 2007 01:43:00 -0000 Message-Id: <1196472622.2501.180.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit 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: 2007-12/txt/msg00002.txt.bz2 On Fri, 2007-11-30 at 16:08 -0800, Jim Blandy wrote: > Michael Snyder writes: > > There will be some as-it-were non-deterministic behavior, > > it seems to me. If threads are running while we are inserting > > breakpoints, then there will (at some point) be breakpoint > > events while we are inserting breakpoints, and the order of > > these events (and of running-threads stopping) will depend > > on the order in which we insert them, as well as on what > > the running threads happen to be doing at the time. > > > > I should think that this would be more intrusive (in the > > sense of changing the behavior of the target program) than > > we already are. > > > > We could see a deadlock develop during the time it takes us > > to insert all the breakpoints. > > Since breakpoints only make the threads that hit them execute "very > slowly", I don't see how they could introduce a deadlock in code that > didn't already have the potential for deadlock in the absence of a > debugger. Well, just 'cause you've changed the timing. Thread A holds a resource that thread B needs; thread A hits a breakpoint but thread B gets to keep running (for a while) because you haven't finished inserting breakpoints. > It's true that the breakpoints won't all appear in the address space > simultaneously. It might be useful to be able to insert breakpoints > disabled, and then enable them as a group. Even in all-stop mode, GDB > isn't able to stop all threads simulataneously; it has to obtain the > list of threads and send each one a signal. So it seems to me that > some degree of 'play' in breakpoint insertion isn't so different from > what we have now. No, it's just more of what is already an intrusive thing. It's worse in degree, not in kind.