Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [non-stop] 08/10 linux native support
Date: Wed, 25 Jun 2008 21:17:00 -0000	[thread overview]
Message-ID: <20080625201946.GH25575@caradoc.them.org> (raw)
In-Reply-To: <200806152205.49241.pedro@codesourcery.com>

On Sun, Jun 15, 2008 at 10:05:49PM +0100, Pedro Alves wrote:
> @@ -920,7 +929,7 @@ delete_lwp (ptid_t ptid)
>  /* Return a pointer to the structure describing the LWP corresponding
>     to PID.  If no corresponding LWP could be found, return NULL.  */
>  
> -static struct lwp_info *
> +struct lwp_info *
>  find_lwp_pid (ptid_t ptid)
>  {
>    struct lwp_info *lp;

If you need this function global, please rename it first.

> @@ -1306,16 +1315,76 @@ get_pending_status (struct lwp_info *lp,
>       events are always cached in waitpid_queue.  */
>  
>    *status = 0;
> -  if (GET_LWP (lp->ptid) == GET_LWP (last_ptid))
> +
> +  if (non_stop)
>      {
> -      if (stop_signal != TARGET_SIGNAL_0
> -	  && signal_pass_state (stop_signal))
> -	*status = W_STOPCODE (target_signal_to_host (stop_signal));
> +      enum target_signal signo = TARGET_SIGNAL_0;
> +
> +      if (is_executing (lp->ptid))
> +	{
> +	  /* If the core thought this lwp was executing, we can only
> +	     have pending events in the local queue.  */
> +	  if (queued_waitpid (GET_LWP (lp->ptid), status, __WALL) != -1)
> +	    {
> +	      if (WIFSTOPPED (status))
> +		signo = target_signal_from_host (WSTOPSIG (status));
> +
> +	      /* If not stopped, then the lwp is gone, no use in
> +		 resending a signal.  */
> +	    }

How do we get here if the core thinks the thread is executing?  Is it
when linux-nat.c resumes the thread without telling the core it
stopped?  A little more detail here would be helpful.

> +      else
> +	{
> +	  /* If the core knows the thread is not executing, then we
> +	     have then last signal recorded in
> +	     thread_info->stop_signal, unless this is inferior_ptid,
> +	     in which case, it's in the global stop_signal, due to
> +	     context switching.  */

I wish we could keep this stuff in the thread struct all the time...

> @@ -1489,6 +1580,9 @@ linux_nat_resume (ptid_t ptid, int step,
>    /* Mark this LWP as resumed.  */
>    lp->resumed = 1;
>  
> +  /* Remove the SIGINT mark.  Used in non-stop mode.  */
> +  lp->sigint = 0;
> +

Confused.  Why does resuming the thread affect whether we have sent it
a SIGINT, but not received it back yet?

> @@ -1650,20 +1746,43 @@ linux_handle_extended_wait (struct lwp_i
>  	  else
>  	    status = 0;
>  
> +	  /* Make thread_db aware of this thread.  We do this this
> +	     early, so in non-stop mode, threads show up as they're
> +	     created, instead of on next stop.  thread_db needs a
> +	     stopped inferior_ptid --- since we know LP is stopped,
> +	     use it this time.  */
> +	  old_chain = save_inferior_ptid ();
> +	  inferior_ptid = lp->ptid;
> +	  lp->stopped = 1;
> +	  target_find_new_threads ();
> +	  do_cleanups (old_chain);
> +	  if (!in_thread_list (new_lp->ptid))
> +	    {
> +	      /* We're not using thread_db.  Attach and add it to
> +		 GDB's list.  */
> +	      lin_lwp_attach_lwp (new_lp->ptid);
> +	      target_post_attach (GET_LWP (new_lp->ptid));
> +	      add_thread (new_lp->ptid);
> +	    }
> +

This may be trouble.  Sometimes the thread state is not
atomically updated, so peeking at it right after creation but before
an event can fail.

Why is it necessary?  We already know the ptid since we made them
independent of thread_db TID some time ago.  attach_thread should cope
if the thread is already in GDB's thread list when the event
eventually arrives.  So we should be able to just add the new
thread directly.

> @@ -2796,13 +2915,26 @@ static int
>  kill_callback (struct lwp_info *lp, void *data)
>  {
>    errno = 0;
> -  ptrace (PTRACE_KILL, GET_LWP (lp->ptid), 0, 0);
> -  if (debug_linux_nat)
> -    fprintf_unfiltered (gdb_stdlog,
> -			"KC:  PTRACE_KILL %s, 0, 0 (%s)\n",
> -			target_pid_to_str (lp->ptid),
> -			errno ? safe_strerror (errno) : "OK");
>  
> +  /* PTRACE_KILL doesn't work when the thread is running.  */
> +  if (!lp->stopped)
> +    {
> +      kill_lwp (GET_LWP (lp->ptid), SIGKILL);
> +      if (debug_linux_nat)
> +	fprintf_unfiltered (gdb_stdlog,
> +			    "KC:  kill_lwp (SIGKILL) %s (%s)\n",
> +			    target_pid_to_str (lp->ptid),
> +			    errno ? safe_strerror (errno) : "OK");
> +    }
> +  else
> +    {
> +      ptrace (PTRACE_KILL, GET_LWP (lp->ptid), 0, 0);
> +      if (debug_linux_nat)
> +	fprintf_unfiltered (gdb_stdlog,
> +			    "KC:  PTRACE_KILL %s, 0, 0 (%s)\n",
> +			    target_pid_to_str (lp->ptid),
> +			    errno ? safe_strerror (errno) : "OK");
> +    }
>    return 0;
>  }
>  

SIGKILL should work even if the thread is stopped.

-- 
Daniel Jacobowitz
CodeSourcery


  reply	other threads:[~2008-06-25 20:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-15 21:10 Pedro Alves
2008-06-25 21:17 ` Daniel Jacobowitz [this message]
2008-06-25 22:03   ` Pedro Alves
2008-06-25 22:12     ` Pedro Alves
2008-06-25 22:52       ` Daniel Jacobowitz
2008-06-25 23:08     ` Daniel Jacobowitz
2008-07-02  3:35       ` Pedro Alves
2008-07-07 18:20         ` Daniel Jacobowitz
2008-07-09  3:25           ` Michael Snyder
2008-07-09  3:47             ` Daniel Jacobowitz
2008-07-09  3:55               ` Michael Snyder
2008-07-09  7:55                 ` Mark Kettenis
2008-07-09  7:56             ` Mark Kettenis
2008-07-10 15:28           ` Pedro Alves
2008-07-10 17:15             ` Daniel Jacobowitz
2008-07-10 18:01               ` Pedro Alves
2008-07-10 19:59                 ` Daniel Jacobowitz
2008-07-10 21:51                   ` Pedro Alves
2008-07-10 22:15                     ` Daniel Jacobowitz
2008-07-10 23:01                       ` 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=20080625201946.GH25575@caradoc.them.org \
    --to=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@codesourcery.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