Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Yao Qi <qiyaoltc@gmail.com>
To: gdb-patches@sourceware.org
Subject: [PATCH 1/8] Set signal to 0 after enqueue_pending_signal
Date: Fri, 04 Mar 2016 10:44:00 -0000	[thread overview]
Message-ID: <1457088276-1170-2-git-send-email-yao.qi@linaro.org> (raw)
In-Reply-To: <1457088276-1170-1-git-send-email-yao.qi@linaro.org>

Today, we enqueue signal in linux_resume_one_lwp_throw, but set
variable 'signal' many lines below with the comment

      /* Postpone any pending signal.  It was enqueued above.  */
      signal = 0;

I feel difficult to associate code across many lines, and we should
move the code close to enqueue_pending_signal call.  This is what
this patch does in general.  After this change, variable 'signal'
is set to zero very early, so the 'signal' value in the following
debugging message makes no sense, so I remove it from the debugging
message.  The function returns early if lwp->status_pending_p is
true, so 'signal' value in the debugging message doesn't matter,
AFAICS.  Also, I move one debugging message several lines below to
make it close the real ptrace call,

  if (debug_threads)
    debug_printf ("Resuming lwp %ld (%s, signal %d, stop %s)\n",
		  lwpid_of (thread), step ? "step" : "continue", signal,
		  lwp->stop_expected ? "expected" : "not expected");

so that the debugging message can reflect what GDBserver does.  This
is a code refactor and only debugging messages are affected.

gdb/gdbserver:

2016-03-04  Yao Qi  <yao.qi@linaro.org>

	* linux-low.c (linux_resume_one_lwp_throw): Set 'signal' to
	0 if signal is enqueued.  Remove 'signal' from one debugging
	message.  Move one debugging message to some lines below.
	Remove code setting 'signal' to 0.
---
 gdb/gdbserver/linux-low.c | 30 +++++++++++++-----------------
 1 file changed, 13 insertions(+), 17 deletions(-)

diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c
index b96248c..4520a4a 100644
--- a/gdb/gdbserver/linux-low.c
+++ b/gdb/gdbserver/linux-low.c
@@ -4164,14 +4164,19 @@ linux_resume_one_lwp_throw (struct lwp_info *lwp,
 	  || lwp->pending_signals != NULL
 	  || lwp->bp_reinsert != 0
 	  || fast_tp_collecting))
-    enqueue_pending_signal (lwp, signal, info);
+    {
+      enqueue_pending_signal (lwp, signal, info);
+
+      /* Postpone any pending signal.  It was enqueued above.  */
+      signal = 0;
+    }
 
   if (lwp->status_pending_p)
     {
       if (debug_threads)
-	debug_printf ("Not resuming lwp %ld (%s, signal %d, stop %s);"
+	debug_printf ("Not resuming lwp %ld (%s, stop %s);"
 		      " has pending status\n",
-		      lwpid_of (thread), step ? "step" : "continue", signal,
+		      lwpid_of (thread), step ? "step" : "continue",
 		      lwp->stop_expected ? "expected" : "not expected");
       return;
     }
@@ -4179,11 +4184,6 @@ linux_resume_one_lwp_throw (struct lwp_info *lwp,
   saved_thread = current_thread;
   current_thread = thread;
 
-  if (debug_threads)
-    debug_printf ("Resuming lwp %ld (%s, signal %d, stop %s)\n",
-		  lwpid_of (thread), step ? "step" : "continue", signal,
-		  lwp->stop_expected ? "expected" : "not expected");
-
   /* This bit needs some thinking about.  If we get a signal that
      we must report while a single-step reinsert is still pending,
      we often end up resuming the thread.  It might be better to
@@ -4213,9 +4213,6 @@ linux_resume_one_lwp_throw (struct lwp_info *lwp,
 
 	  step = 1;
 	}
-
-      /* Postpone any pending signal.  It was enqueued above.  */
-      signal = 0;
     }
 
   if (fast_tp_collecting == 1)
@@ -4224,9 +4221,6 @@ linux_resume_one_lwp_throw (struct lwp_info *lwp,
 	debug_printf ("lwp %ld wants to get out of fast tracepoint jump pad"
 		      " (exit-jump-pad-bkpt)\n",
 		      lwpid_of (thread));
-
-      /* Postpone any pending signal.  It was enqueued above.  */
-      signal = 0;
     }
   else if (fast_tp_collecting == 2)
     {
@@ -4243,9 +4237,6 @@ linux_resume_one_lwp_throw (struct lwp_info *lwp,
 			  "moving out of jump pad single-stepping"
 			  " not implemented on this target");
 	}
-
-      /* Postpone any pending signal.  It was enqueued above.  */
-      signal = 0;
     }
 
   /* If we have while-stepping actions in this thread set it stepping.
@@ -4300,6 +4291,11 @@ linux_resume_one_lwp_throw (struct lwp_info *lwp,
       *p_sig = NULL;
     }
 
+  if (debug_threads)
+    debug_printf ("Resuming lwp %ld (%s, signal %d, stop %s)\n",
+		  lwpid_of (thread), step ? "step" : "continue", signal,
+		  lwp->stop_expected ? "expected" : "not expected");
+
   if (the_low_target.prepare_to_resume != NULL)
     the_low_target.prepare_to_resume (lwp);
 
-- 
1.9.1


  parent reply	other threads:[~2016-03-04 10:44 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-04 10:44 [PATCH 0/8] Step over instruction branches to itself Yao Qi
2016-03-04 10:44 ` [PATCH 3/8] Deliver signal in hardware single step Yao Qi
2016-03-11 11:05   ` Pedro Alves
2016-03-11 11:09     ` Pedro Alves
2016-03-11 11:37       ` Pedro Alves
2016-03-16 10:47         ` Yao Qi
2016-03-17 12:12           ` Pedro Alves
2016-03-04 10:44 ` Yao Qi [this message]
2016-03-11 10:53   ` [PATCH 1/8] Set signal to 0 after enqueue_pending_signal Pedro Alves
2016-03-18 14:36     ` Yao Qi
2016-03-04 10:44 ` [PATCH 7/8] Resume the inferior with signal rather than stepping over Yao Qi
2016-03-11 12:04   ` Pedro Alves
2016-03-21  9:40     ` Yao Qi
2016-03-04 10:44 ` [PATCH 4/8] Force to insert software single step breakpoint Yao Qi
2016-03-11 11:49   ` Pedro Alves
2016-03-16 11:47     ` Yao Qi
2016-03-17 12:40       ` Pedro Alves
2016-03-18 14:25         ` Yao Qi
2016-03-18 15:03           ` Pedro Alves
2016-03-04 10:44 ` [PATCH 2/8] Check LWP_SIGNAL_CAN_BE_DELIVERED for enqueue/dequeue pending signals Yao Qi
2016-03-11 10:55   ` Pedro Alves
2016-03-17  8:40     ` Yao Qi
2016-03-17 11:07       ` Pedro Alves
2016-03-18 14:36         ` Yao Qi
2016-03-16 17:02   ` Luis Machado
2016-03-04 10:44 ` [PATCH 6/8] [GDBserver] Don't error in reinsert_raw_breakpoint if bp->inserted Yao Qi
2016-03-04 10:45 ` [PATCH 8/8] New test case gdb.base/branch-to-self.exp Yao Qi
2016-03-04 10:45 ` [PATCH 5/8] Insert breakpoint even when the raw breakpoint is found Yao Qi
2016-03-11 11:54   ` 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=1457088276-1170-2-git-send-email-yao.qi@linaro.org \
    --to=qiyaoltc@gmail.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