Re: [RFC] 10/10 non-stop for linux native

[Michael Snyder <msnyder@specifix.com>]

On Fri, 2008-05-09 at 02:53 +0100, Pedro Alves wrote:
> A Thursday 08 May 2008 12:47:56, Eli Zaretskii wrote:
> > > From: Pedro Alves <pedro@codesourcery.com>
> > > Date: Tue, 6 May 2008 16:50:10 +0100
> > >
> > > This adds non-stop support for linux native.
> > >
> > > The changes are:
> > >
> > > - ptracing a running thread doesn't work.
> > >
> > >  This implies that, we must ensure that the proc_services
> > >  usage in linux-thread-db.c talks to a pid of a stopped lwp.
> > >
> > >  Checking if a thread is alive with ptrace doesn't work
> > >  for running threads.  Worse, ptrace errors out claiming
> > >  the thread doesn't exits.
> > >
> > > - We must not stop all threads, obviously.
> > >
> > > - We must mark threads as running if we're resuming
> > >  them behind the core's back.
> > >
> > > - Implement target_stop_ptid to interrupt only one thread
> >
> > I know nothing about the Linux kernel or ptrace implementation, but
> > the above description sounds as if we are coding around ptrace/kernel
> > bugs.  Are we?
> 
> It's just how ptrace works.  There are some things that could be
> changed, but we have added workarounds for real bugs in that past,
> and these are not bugs, more like the "personality" of the mostly
> unspecified behaviour of ptrace.
> 
> ptrace only works against a stopped lwp.
> 
> That being said, the most surprising ptrace issue is returning
> ESRCH on a running threads, which makes the target_thread_alive
> return wrong results for running threads.

We are extending the envelope here.  Ptrace was not designed
with non-stop or asynch debugging in mind.