From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18786 invoked by alias); 3 Dec 2007 18:14:13 -0000 Received: (qmail 18775 invoked by uid 22791); 3 Dec 2007 18:14:13 -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; Mon, 03 Dec 2007 18:14:02 +0000 Received: (qmail 4088 invoked from network); 3 Dec 2007 18:14:00 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 Dec 2007 18:14:00 -0000 To: Thiago Jung Bauermann Cc: Michael Snyder , 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> <1196472622.2501.180.camel@localhost.localdomain> <8f2776cb0712010952y5330258akfe3086287f59ccb9@mail.gmail.com> <1196620597.6746.179.camel@localhost.localdomain> From: Jim Blandy Date: Mon, 03 Dec 2007 18:14:00 -0000 In-Reply-To: <1196620597.6746.179.camel@localhost.localdomain> (Thiago Jung Bauermann's message of "Sun, 02 Dec 2007 16:36:37 -0200") 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/msg00013.txt.bz2 Thiago Jung Bauermann writes: > On Sat, 2007-12-01 at 09:52 -0800, Jim Blandy wrote: >> On Nov 30, 2007 5:30 PM, Michael Snyder wrote: >> The original concern you raised was that non-stop debugging is "more >> intrusive than we already are". But clearly all-stop debugging on a >> live system is maximally intrusive to the system's users; non-stop >> debugging has the potential to be much less intrusive, when used with >> knowledge of the interactions between the system's threads. > > There are cases when a developer will want to use non-stop debugging but > minimize change of relative timing of threads. Suppose that a developer > is trying to debug a deadlock situation in a program with 3 threads. A > and B are deadlocking, and C is a "supporting" thread without which the > other two can't run. He can't use all-stop debugging because while > inspecting A and B, C needs to be running. In this case, relative timing > of threads is important in order to have better chance at reproducing > the deadlock. Something that would be nice would be the ability to define "thread groups", that you could stop and start as a group, restrict breakpoints to, and so on. You could put A and B in a thread group, and leave C out of it. That kind of feature would be straightforward to implement in terms of the non-stop debugging we're doing now.