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

[Pedro Alves <pedro at codesourcery dot com>]

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.

You can also see similar results by:
 sudo cat /proc/10/mem
 cat: /proc/10/mem: No such process

> If we are, isn't it better to solve these bugs in 
> ptrace first?  And if we do work around these bugs as suggested in
> this patch, won't that be a maintenance burden once the kernel people
> start fixing it in some future Linux version?
>

Not really.  If the kernel was "fixed", the code I'm adding should
still work.  Plus, most of what I'm adding are not workarounds.

I don't think this patch and the "extra maintenance burden"
is significant enough to warrant any ptrace redesign on the
kernel side, and requiring everyone to upgrade their kernels
to have access to non-stop.  Plus, other ptrace OSs should have
the same issues, even the closed-source ones.

> Sorry if these are silly questions out of ignorance.

Not at all.

-- 
Pedro Alves