Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Michael Snyder <msnyder@specifix.com>,  Eli Zaretskii <eliz@gnu.org>
Subject: Re: [RFC] 10/10 non-stop for linux native
Date: Sat, 10 May 2008 02:54:00 -0000	[thread overview]
Message-ID: <200805092117.56176.pedro@codesourcery.com> (raw)
In-Reply-To: <1210361218.4615.516.camel@localhost.localdomain>

A Friday 09 May 2008 20:26:58, Michael Snyder wrote:

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

I'm not relying on some unspecified ptrace behaviour
against running lwps that happens to be convenient.

With ptrace, we can inspect and modify inferior processes
while they are stopped, only.  It they are running, we can't
read registers or memory from them.

I'm simply ensuring never to use ptrace against a running
lwp, ever.

The only two "issues" with ptrace here, but those only arose,
because we assumed all lwps were always stopped.

We were always talking to thread-db through the the main lwp of the
thread group (proc-service.c/linux-thread-db.c:proc_handle.pid).
In all-stop that is ok, as all lwps are stopped at that point.  In
non-stop, when some other lwp other then the main lwp gets an
event (a breakpoint, say), since we don't stop all threads,
proc-service would fail -- the main lwp could be running.  But,
we know the event lwp is stopped at that point, so we should have 
proc_services use the event pid -- because we can use ptrace on it.

The other issue is that linux_nat_thread_alive assumed the passed in
ptid is stopped when it is called, because that is always true in all-stop
mode.  Since that is not true in non-stop, I switched the linux
implementation to check if the lwp is alive by "sending" signal 0
instead of relying on ptrace(PEEK_USER).

-- 
Pedro Alves


  reply	other threads:[~2008-05-09 20:18 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
2008-05-09 22:10     ` Michael Snyder
2008-05-10  2:54       ` Pedro Alves [this message]
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=200805092117.56176.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=msnyder@specifix.com \
    /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