From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23579 invoked by alias); 6 Apr 2007 22:12:10 -0000 Received: (qmail 23571 invoked by uid 22791); 6 Apr 2007 22:12:09 -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; Fri, 06 Apr 2007 23:12:07 +0100 Received: (qmail 22527 invoked from network); 6 Apr 2007 22:12:06 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Apr 2007 22:12:06 -0000 To: Emi SUZUKI Cc: gdb@sourceware.org Subject: Re: single-stepping and internal breakpoints on a multi-threaded program References: <20070405.205731.12335149.emi-suzuki@tjsys.co.jp> From: Jim Blandy Date: Fri, 06 Apr 2007 22:12:00 -0000 In-Reply-To: <20070405.205731.12335149.emi-suzuki@tjsys.co.jp> (Emi SUZUKI's message of "Thu, 05 Apr 2007 20:57:31 +0900") 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-04/txt/msg00039.txt.bz2 Emi SUZUKI writes: > The attached program makes two sub threads, and we do single-stepping > on one of them. > When the target get stopped by a internal breakpoint hit (ex. thread > creation, thread death, shared library loading) during singe-stepping, > GDB unconditionally resume all the thread and it result in running > over the range of single-stepping. I'm able to reproduce this problem on my FC6 x86 dual core system. Thanks very much for the clear reproduction instructions. > I saw that the context of single-stepping thread is preserved by > context_switch called in handle_inferior_event, but GDB doesn't go > back to that context till the thread is trapped in another reason > (in the above case, the death of the thread). > > I think it should either stop immediately and prompt the user that the > single-stepping has been cancelled, or goes back to the preserved > context somehow and continue single-stepping. > How do you think of it? So, if I'm understanding correctly, we single-step the 'counter' thread, which proceeds normally until the 'no_counter' thread hits its TD_CREATE event, to tell GDB about its existence. Then, GDB fails to resume single-stepping the 'counter' thread, letting it run until it exits and reports its TD_DEATH event. The fact that the inferior uses breakpoints to report thread creation and thread death is supposed to be an internal detail of the thread library --- or, more properly, of the thread debugging interface. One thread stepping shouldn't be affected by other threads being created (although GDB should still print the 'new thread' messages). So I think the right behavior would be for GDB to continue single-stepping after processing creation and death events for other threads. I have forgetten exactly how GDB handles multi-threaded single stepping; I'm afraid I can't suggest how to do this. If you're unable to fix it yourself, please file a bug report, and include your test program.