Re: [PATCH v2 15/23] Implement all-stop on top of a target running non-stop mode

[Pedro Alves <palves at redhat dot com>]

On 04/08/2015 10:52 AM, Pedro Alves wrote:
> On 04/08/2015 10:34 AM, Yao Qi wrote:
>> Pedro Alves <palves@redhat.com> writes:
>>
>>> @@ -1997,7 +1998,7 @@ start_step_over_inferior (struct inferior *inf)
>>>  	{
>>>  	  /* In all-stop, we shouldn't have resumed unless we needed a
>>>  	     step over.  */
>>> -	  gdb_assert (non_stop);
>>> +	  gdb_assert (target_is_non_stop_p ());
>>>  	}
>>>      }
>>
>> Hi Pedro,
>> I tested the whole series on arm-linux and there is an assert triggered
>> with gdbserver,
>>
>> signal SIGTRAP^M
>> Continuing with signal SIGTRAP.^M
>> ../../../binutils-gdb/gdb/infrun.c:2008: internal-error: start_step_over_inferior: Assertion `target_is_non_stop_p ()' failed.^M
>> A problem internal to GDB has been detected,^M
>> further debugging may prove unreliable.^M
>> Quit this debugging session? (y or n) FAIL: gdb.threads/signal-sigtrap.exp: sigtrap thread 2: signal SIGTRAP reaches handler (GDB internal error)
>>
>> there is no such internal error in native testing.  I haven't analyse it
>> carefully yet.
> 
> Interesting.  I hadn't tested gdbserver with the series applied on
> top of my x86-64 software single-step branch.  But running signal-sigtrap.exp
> against that trips on that assert too.  The test does passes cleanly against
> gdbserver with hardware single-step (x86-64).  I'll take a look.


The issue is that the thread that we're starting a new step-over on
has a signal to deliver as well.  So 'resume' reaches the:

  /* Currently, our software single-step implementation leads to different
     results than hardware single-stepping in one situation: when stepping
     into delivering a signal which has an associated signal handler,
     hardware single-step will stop at the first instruction of the handler,
     while software single-step will simply skip execution of the handler.

... part.  This clears trap_expected, which results in that assertion.

Hmm.  Looks like the assertion caught a pre-existing problem.
This sets up the thread to re-hit the breakpoint at PC once the
signal handler returns, and lets _all_ threads run.  But, what if had
_other_ threads that needed a step-over too?  Those will run too,
and immediately re-trap the same breakpoint, but GDB will re-report them.
Maybe we should set a step-resume breakpoint on _all_ threads that need
a step-over, not just the current.  I'll need to think a bit about this.

Thanks,
Pedro Alves