This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 3/8] Deliver signal in hardware single step
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>, gdb-patches at sourceware dot org
- Date: Fri, 11 Mar 2016 11:05:41 +0000
- Subject: Re: [PATCH 3/8] Deliver signal in hardware single step
- Authentication-results: sourceware.org; auth=none
- References: <1457088276-1170-1-git-send-email-yao dot qi at linaro dot org> <1457088276-1170-4-git-send-email-yao dot qi at linaro dot org>
On 03/04/2016 10:44 AM, Yao Qi wrote:
> GDBserver doesn't deliver signal when stepping over a breakpoint even
> hardware single step is used. When GDBserver started to step over
> (thread creation) breakpoint for mutlit-threaded debugging in 2002 [1],
> GDBserver behaves this way.
>
> This behaviour gets trouble on conditional breakpoints on branch to
> self instruction like this,
>
> 0x00000000004005b6 <+29>: jmp 0x4005b6 <main+29>
>
> and I set breakpoint
>
> $(gdb) break branch-to-self.c:43 if counter > 3
>
> and the variable counter will be set to 5 in SIGALRM signal handler.
> Since GDBserver keeps stepping over breakpoint, the SIGALRM can never
> be dequeued and delivered to the inferior, so the program can't stop.
> The test can be found in gdb.base/branch-to-self.exp.
>
> I can understand why does GDBserver queue signal for software single
> step, but I can't figure out a reason we should queue signal for
> hardware single step. With this patch applied, GDBserver forward the
> signal to inferior and the program can stop correctly.
>
> [1] PATCH: Multithreaded debugging for gdbserver
> https://sourceware.org/ml/gdb-patches/2002-06/msg00157.html
>
Because the signal handler might recurse and call the same code
that had the breakpoint (or some other removed breakpoint), and thus
we'd miss a breakpoint hit in the signal handler.
GDB / infrun.c handles it here:
if (ecs->event_thread->prev_pc == stop_pc
&& ecs->event_thread->control.trap_expected
&& ecs->event_thread->control.step_resume_breakpoint == NULL)
{
int was_in_line;
/* We were just starting a new sequence, attempting to
single-step off of a breakpoint and expecting a SIGTRAP.
Instead this signal arrives. This signal will take us out
of the stepping range so GDB needs to remember to, when
the signal handler returns, resume stepping off that
breakpoint. */
/* To simplify things, "continue" is forced to use the same
code paths as single-step - set a breakpoint at the
signal return address and then, once hit, step off that
breakpoint. */
IIRC, some of sigstep.exp, signull.exp, signest.exp exercise this.
Note that this also lets all threads run while the signal
handler runs.
Thanks,
Pedro Alves