From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3773 invoked by alias); 13 Aug 2007 21:37:24 -0000 Received: (qmail 3652 invoked by uid 22791); 13 Aug 2007 21:37:23 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 13 Aug 2007 21:37:18 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 8D6D198308; Mon, 13 Aug 2007 21:37:18 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 689F998104; Mon, 13 Aug 2007 21:37:18 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1IKhb9-0006k3-Vq; Mon, 13 Aug 2007 17:37:15 -0400 Date: Mon, 13 Aug 2007 21:37:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: [rfc] Delay deletion of step-resume breakpoints Message-ID: <20070813213715.GA25303@caradoc.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sourceware.org References: <20070813210326.GA24049@caradoc.them.org> <200708132113.l7DLDWEw021526@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708132113.l7DLDWEw021526@brahms.sibelius.xs4all.nl> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-08/txt/msg00260.txt.bz2 On Mon, Aug 13, 2007 at 11:13:32PM +0200, Mark Kettenis wrote: > The change you made to the comment: > > > /* NOTE: this will take care of any left-over step_resume breakpoints, > > - but not any user-specified thread-specific breakpoints. */ > > + but not any user-specified thread-specific breakpoints. We can not > > + delete the breakpoint straight-off, because the inferior might not > > + be stopped at the moment. */ > > Makes me suspect this is just a workaround for another bug, the bug > being that the inferior isn't properly stopped when this code gets > called. That's supposed to be not a bug - I think. We've detected a thread exit while waiting for an interesting event; since thread exit isn't generally considered "interesting" in this context, we keep waiting. If your OS stops all threads for you at every event (HP/UX ttrace does, I think) then that doesn't matter. If your OS doesn't (Solaris PR_ASYNC, GNU/Linux) then you might detect that thread exit while the other threads are not yet stopped. Or something else might have already resumed the other threads; I am working on remote protocol notifications for stopped threads, and I don't want to leave the entire target stopped while waiting for GDB to ack. Jim's come up with a sensible design I can reuse for this, we'll post it soon I hope. So we can delay deleting the thread until the next time we need to stop all threads, but that's awkward - see record_dead_thread in linux-nat.c. Or we can let delete_thread handle the problem. So should delete_thread be callable when the target is running or should any target that might call it when the target is not running maintain its own list the way the Linux native layer does? We don't have any formal specifications on what can be called when :-( -- Daniel Jacobowitz CodeSourcery