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

Pedro Alves
2015-04-08T11:08:20Z

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