From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24421 invoked by alias); 30 Nov 2007 21:41:06 -0000 Received: (qmail 24413 invoked by uid 22791); 30 Nov 2007 21:41:05 -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; Fri, 30 Nov 2007 21:40:55 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 4CCAE3BEC9; Fri, 30 Nov 2007 13:40:53 -0800 (PST) Subject: Re: Keeping breakpoints inserted From: Michael Snyder To: Thiago Jung Bauermann Cc: Vladimir Prus , gdb@sources.redhat.com In-Reply-To: <1196456622.6746.169.camel@localhost.localdomain> References: <200711292224.23659.vladimir@codesourcery.com> <1196456622.6746.169.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 30 Nov 2007 21:41:00 -0000 Message-Id: <1196458063.2501.153.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-11/txt/msg00302.txt.bz2 On Fri, 2007-11-30 at 19:03 -0200, Thiago Jung Bauermann wrote: > Hi, > > On Thu, 2007-11-29 at 22:24 +0300, Vladimir Prus wrote: > > Anybody has comments on this approach? > > When adding and removing breakpoints, will GDB stop all threads or just > the one under inspection? > > On first thought, I think that if adding a breakpoint can be done > atomically (i.e., trap instruction is 1 word wide), then it wouldn't be > necessary to stop other threads. Am I being too naive here? 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.