This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] 10/10 non-stop for linux native
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.