From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5108 invoked by alias); 17 Mar 2008 22:05:44 -0000 Received: (qmail 4871 invoked by uid 22791); 17 Mar 2008 22:05:43 -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, 17 Mar 2008 22:05:19 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 6B77D983BF; Mon, 17 Mar 2008 22:05:16 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 531E198011; Mon, 17 Mar 2008 22:05:16 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JbNSF-0000ku-9d; Mon, 17 Mar 2008 18:05:15 -0400 Date: Mon, 17 Mar 2008 22:05:00 -0000 From: Daniel Jacobowitz To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: linux native async mode support Message-ID: <20080317220515.GA1309@caradoc.them.org> Mail-Followup-To: Pedro Alves , gdb-patches@sourceware.org References: <200803140810.22883.pedro@codesourcery.com> <20080314211646.GK31663@caradoc.them.org> <200803171605.24276.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200803171605.24276.pedro@codesourcery.com> User-Agent: Mutt/1.5.17 (2007-12-11) 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: 2008-03/txt/msg00247.txt.bz2 On Mon, Mar 17, 2008 at 04:05:24PM +0000, Pedro Alves wrote: > > > @@ -516,6 +707,12 @@ linux_child_follow_fork (struct target_o > > > target_detach (which does other necessary cleanup). */ > > > > > > push_target (ops); > > > + > > > + if (async_was_enabled && !linux_nat_async_enabled) > > > + /* target_detach may disable async depending on multi-threaded > > > + enabled or not. Reenable it if needed. */ > > > + linux_nat_enable_async (); > > > + > > > linux_nat_switch_fork (inferior_ptid); > > > check_for_thread_db (); > > > > This will drain the queue, losing any pending events. In non-stop > > mode I can imagine that causing trouble. Maybe we need to avoid > > target_detach now. > > > > Yeah. Here's how I fixed it: target_detach, when the target is > multi-threaded, would call thread_db_detach, which calls > target_mourn_inferior. The mourn inferior call (although most targets > don't mourn on detach), is there AFAICT mostly to reset > using_thread_db. There's nothing in linux_nat_mourn_inferior that > we'd miss. Notice that linux_nat_detach doesn't mourn, so a > single-threaded inferior doesn't get mourned. > > So, I split linux_nat_detach in two (linux_nat_detach_inferior, and > linux_nat_detach proper which calls linux_nat_detach_inferior), and > added a re_check_for_thread_db, to be used after following the child, > so thread_db knows about the new current inferior. I don't like this :-( There's more that thread_db_attach does. If we don't disable thread event reporting, then it's likely to stop and wait for the debugger the next time it creates a thread. Yes, this was already broken when following a vfork. And it may be broken if the child creates threads when we follow the parent of a fork. But if we can avoid breaking it further, that would be nice. Do we really have to disable async when detaching? Maybe we could do so only at attach and create, if it doesn't matter how async is set the rest of the time. Remove the normal_mask / blocked_mask bits from linux_nat_disable_async and call it in else blocks after the two calls to linux_nat_enable_async. What do you think? Other than this one bit, the new patch looks good to me. -- Daniel Jacobowitz CodeSourcery