Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: dje@google.com (Doug Evans)
To: gdb-patches@sourceware.org
Subject: [RFA]: handle_extended_wait: Call linux_resume_one_lwp instead of ptrace
Date: Sun, 24 May 2009 03:14:00 -0000	[thread overview]
Message-ID: <20090524031422.C486F846C2@localhost> (raw)

Hi.

There are some things that linux_resume_one_lwp does that either
all callers of ptrace (PTRACE_CONT) should do (check errno)
or would be nice to do (print a debugging message).
I was thinking of splitting linux_resume_one_lwp into two,
but since the newly created thread is, well, new the rest of
linux_resume_one_lwp is a nop; so it seems reasonable to just call
linux_resume_one_lwp for the new thread.
It's also nice to have all calls to ptrace (PTRACE_CONT)
routed through one function.

Ok to check in?
[tested on amd64 w/ --target_board=native-gdbserver, no regressions]

2009-05-23  Doug Evans  <dje@google.com>

	* linux-low.c (handle_extended_wait): Use linux_resume_one_lwp
	to resume the newly created thread, don't call ptrace (PTRACE_CONT)
	directly.

Index: linux-low.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/linux-low.c,v
retrieving revision 1.103
diff -u -p -r1.103 linux-low.c
--- linux-low.c	24 May 2009 01:09:22 -0000	1.103
+++ linux-low.c	24 May 2009 03:00:53 -0000
@@ -295,29 +295,32 @@ handle_extended_wait (struct lwp_info *e
       new_lwp = (struct lwp_info *) add_lwp (ptid);
       add_thread (ptid, new_lwp);
 
+      /* Either we're going to immediately resume the new thread
+	 or leave it stopped.  linux_resume_one_lwp is a nop if it
+	 thinks the thread is currently running, so set this first
+	 before calling linux_resume_one_lwp.  */
+      new_lwp->stopped = 1;
+
       /* Normally we will get the pending SIGSTOP.  But in some cases
 	 we might get another signal delivered to the group first.
 	 If we do get another signal, be sure not to lose it.  */
       if (WSTOPSIG (status) == SIGSTOP)
 	{
-	  if (stopping_threads)
-	    new_lwp->stopped = 1;
-	  else
-	    ptrace (PTRACE_CONT, new_pid, 0, 0);
+	  if (! stopping_threads)
+	    linux_resume_one_lwp (new_lwp, 0, 0, NULL);
 	}
       else
 	{
 	  new_lwp->stop_expected = 1;
 	  if (stopping_threads)
 	    {
-	      new_lwp->stopped = 1;
 	      new_lwp->status_pending_p = 1;
 	      new_lwp->status_pending = status;
 	    }
 	  else
 	    /* Pass the signal on.  This is what GDB does - except
 	       shouldn't we really report it instead?  */
-	    ptrace (PTRACE_CONT, new_pid, 0, WSTOPSIG (status));
+	    linux_resume_one_lwp (new_lwp, 0, WSTOPSIG (status), NULL);
 	}
 
       /* Always resume the current thread.  If we are stopping


             reply	other threads:[~2009-05-24  3:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-24  3:14 Doug Evans [this message]
2009-05-24 17:00 ` Pedro Alves

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=20090524031422.C486F846C2@localhost \
    --to=dje@google.com \
    --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