From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org, Eli Zaretskii <eliz@gnu.org>
Subject: Re: [RFC] 10/10 non-stop for linux native
Date: Fri, 09 May 2008 03:25:00 -0000 [thread overview]
Message-ID: <200805090253.21680.pedro@codesourcery.com> (raw)
In-Reply-To: <uzlr1m2z7.fsf@gnu.org>
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
next prev parent reply other threads:[~2008-05-09 1:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-06 18:31 Pedro Alves
2008-05-08 18:30 ` Eli Zaretskii
2008-05-09 3:25 ` Pedro Alves [this message]
2008-05-09 22:10 ` Michael Snyder
2008-05-10 2:54 ` Pedro Alves
2008-05-19 17:20 ` Pedro Alves
2008-06-25 20:25 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200805090253.21680.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox