Re: [PATCH v3 10/17] Implement all-stop on top of a target running non-stop mode

[Pedro Alves <palves@redhat.com>]

Hi Yao,

I had not realized I missed answering this.

On 04/24/2015 08:39 AM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>>> This path is about the case that a signal is got while in in-line
>>> stepping, isn't?  If so, non_stop should be an invariant false.  We
>>> don't need to check it.
>>
>> Hmm, not sure what you mean:
>>
> 
> Let me ask it in another way, when we get here, it means a signal
> arrived, the code some lines above is:
> 
>           if (debug_infrun)
>             fprintf_unfiltered (gdb_stdlog,
>                                 "infrun: signal arrived while stepping over "
>                                 "breakpoint\n");
> 
> GDB just did the breakpoint step over, via in-line stepping or
> out-of-line stepping, right? as your patch below shows.
> 
>>  - We need to do this with displaced stepping too, because we can't
>>    deliver signals while doing a displaced step.  See comments at the
>>    top of displaced_step_prepare and in do_target_resume.
> 
> The first sentence is contradictory, or you mean we *can* do either
> out-of-line stepping or in-line stepping, but we can't deliver a signal
> while doing a displaced stepping...

By "need to do this" I meant that we need to cancel the step over in
progress, and insert the step-resume at the signal handlers return.

> 
>>
>>  - We can certainly get a signal while doing an in-line step-over.
>>    The simplest would be, trying to step-over a breakpoint here:
>>
>>       *(volatile int *)0 = 1;
>>
>>    which usually results SIGSEGV.
> 
> ... while we can deliver a signal in in-line stepping.  Is it correct?
> 

Not really.

We can't deliver a signal while a displaced step is in
progress, because we wouldn't be able to tell whether the thread stepped
to the handler or to main line code, so we wouldn't know whether to apply
the displaced step fixup.  Also, if the thread stops for some reason while
in the handler, we'd end up with the scratch pad still in the frame chain,
so later when the thread is re-resumed, it'd return to the scratch pad, but
the scratch pad would have already have been overwritten.

And we can't deliver a signal while stepping over a breakpoint in-line
either, because that requires removing the breakpoint, and the signal handler
can recurse and call the same code that had the breakpoint we were
stepping over -- which would mean we'd miss trapping on that breakpoint.
(this is tested by signest.exp).

So the only difference between stepping over a breakpoint in-line or
out-of-line here, is that with the former, threads had been previously
paused, so we re-resume them while the signal handler runs (to avoid
debugger-induced inferior deadlock).

Let me know if that answered your question.

Thanks,
Pedro Alves