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:37:40 +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> <56E2A685 dot 2080602 at redhat dot com> <56E2A753 dot 9060805 at redhat dot com>
On 03/11/2016 11:09 AM, Pedro Alves wrote:
> On 03/11/2016 11:05 AM, Pedro Alves wrote:
>> 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.
>
> Hmm, no, I got confused. We'll stop in first instruction in the signal
> handler. Let me go back and take a fresh look.
OK, trying to think of scenarios that might break. Haven't actually
tried them, I may have missed something.
- If there's no handler installed at all (SIG_IGN), then we'll
manage to step over the breakpoint successfully and stop at the
next instruction. So this case is not an issue.
- If there's a signal handler installed, we'll stop at its entry,
but we haven't stepped over the original breakpoint yet. If we
were already stopped at the entry of the signal handler, and it
nested, we'll find the program stopped at the same PC it had
started at. But we won't know whether the step-over finished
successfully (could be a "jmp $pc" instruction), or if instead we're
in a new handler invocation, and thus this is a new,
separate breakpoint hit.
A signal handler that segfaults in the first instruction
would be the easiest way to reproduce this that I can think of.
(If it's crashing, you'd expect the user might try putting a
breakpoint there.)
Now, if after stepping into the handler, we immediately reinsert the
breakpoint and continue, we'll retrap it, it ends up OK.
But if we immediately instead start a new step-over for the same
breakpoint address, we will miss the new hit, and nest a new handler,
on and on.
Not sure which happens, but I suspect the latter.
Maybe we could detect this by comparing before / after
stack pointer.
Thanks,
Pedro Alves