Re: [PATCH 3/8] Deliver signal in hardware single step

[Pedro Alves <palves 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