aboutsummaryrefslogtreecommitdiff
path: root/elfcpp
diff options
context:
space:
mode:
authorYao Qi <yao.qi@linaro.org>2016-03-18 14:31:40 +0000
committerYao Qi <yao.qi@linaro.org>2016-03-18 14:31:40 +0000
commit94610ec4ee630e677d15361353796cac17339c53 (patch)
treead4bdcd29d4ecfa13176a5b7c9d4e968d3724090 /elfcpp
parent80aea927cc7bf97a2bc22e1fb2111c52be295e8b (diff)
downloadbinutils-94610ec4ee630e677d15361353796cac17339c53.zip
binutils-94610ec4ee630e677d15361353796cac17339c53.tar.gz
binutils-94610ec4ee630e677d15361353796cac17339c53.tar.bz2
Set signal to 0 after enqueue_pending_signal
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-18 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.
Diffstat (limited to 'elfcpp')
0 files changed, 0 insertions, 0 deletions