From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12502 invoked by alias); 1 Dec 2007 00:08:45 -0000 Received: (qmail 12493 invoked by uid 22791); 1 Dec 2007 00:08:45 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 01 Dec 2007 00:08:39 +0000 Received: (qmail 31829 invoked from network); 1 Dec 2007 00:08:37 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Dec 2007 00:08:37 -0000 To: Michael Snyder Cc: Thiago Jung Bauermann , Vladimir Prus , gdb@sources.redhat.com Subject: Re: Keeping breakpoints inserted References: <200711292224.23659.vladimir@codesourcery.com> <1196456622.6746.169.camel@localhost.localdomain> <1196458063.2501.153.camel@localhost.localdomain> From: Jim Blandy Date: Sat, 01 Dec 2007 00:08:00 -0000 In-Reply-To: <1196458063.2501.153.camel@localhost.localdomain> (Michael Snyder's message of "Fri, 30 Nov 2007 13:27:43 -0800") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00000.txt.bz2 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. 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. Inserting breakpoints into code that's currently being executed inevitably entails race conditions. But I expect one would only do such a thing in circumstances where it's meaningful and controllable. For example, you might know that you'll reach the breakpoint only in response to a certain input, which you'll send to the program after you've set the breakpoint. Or, it might not matter which particular execution of the code you catch first, you just want to interrupt it. Non-stop debugging is more invasive than all-stop debugging, if you assess invasiveness by looking at how the threads progress relative to each other. Non-stop debugging can make one thread run 'extremely slowly' while other threads progress at a normal rate. All-stop debugging stops all threads roughly equally (but even then not perfectly so). However, non-stop debugging can be less invasive than all-stop debugging, if you assess invasiveness by looking at how responsive the system remains to outside events. With non-stop debugging, you can debug one particular thread out of the entire system while the others continue to work normally. Deciding which mode to use depends on the developer's knowledge of the system they're debugging.