[1/8] Set signal to 0 after enqueue_pending_signal
Commit Message
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(-)
Comments
On 03/04/2016 10:44 AM, Yao Qi wrote:
> 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.
OK.
Thanks,
Pedro Alves
Pedro Alves <palves@redhat.com> writes:
>> 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.
>
> OK.
Patch is pushed in.
@@ -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);