This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: linux native async mode support
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