Re: [PATCH v2] arm64: Store breakpoint single step state into pstate

["Wangnan (F)" <wangnan0@huawei.com>]

On 2016/1/5 0:55, Will Deacon wrote:
> Hello,
>
> On Thu, Dec 24, 2015 at 01:42:42AM +0000, Wang Nan wrote:
>> Two 'perf test' fail on arm64:
>>
>>   # perf test overflow
>>   17: Test breakpoint overflow signal handler                  : FAILED!
>>   18: Test breakpoint overflow sampling                        : FAILED!
>>
>> When breakpoint raises, after perf_bp_event, breakpoint_handler()
>> temporary disables breakpoint and enables single step. Then in
>> single_step_handler(), reenable breakpoint. Without doing this
>> the breakpoint would be triggered again.
>>
>> However, if there's a pending signal and it have signal handler,
>> control would be transfer to signal handler, so single step handler
>> would be applied to the first instruction of signal handler. After
>> the handler return, the instruction triggered the breakpoint would be
>> executed again. At this time the breakpoint is enabled, so the
>> breakpoint is triggered again.
> Whilst I appreciate that you're just trying to get those tests passing
> on arm64, I really don't think its a good idea for us to try and emulate
> the x86 debug semantics here. This doesn't happen for ptrace, and I think
> we're likely to break more than we fix if we try to do it for perf too.
>
> The problem seems to be that we take the debug exception before the
> breakpointed instruction has been executed and call perf_bp_event at
> that moment, so when we single-step the faulting instruction we actually
> step into the SIGIO handler and end up getting stuck.

Understand.

> Your fix doesn't really address this afaict,

I don't think so. After applying my patch, the entry of signal handler won't
be single-stepped. Please have a look at signal_toggle_single_step(): when
signal arises, single step handler is turned off, so signal handler won't
be stepped.

I thing the following 4 cases you mentioned should not causes error in 
theory:

>   in that you don't (can't?)
> handle:
>
>    * A longjmp out of a signal handler

The signal frame is dropped so stepping is omitted.

>    * A watchpoint and a breakpoint that fire on the same instruction

Watchpoints and breakpoints are controlled separatly. In this case it would
generated twp nested signals. I will try this.

>    * User-controlled single-step from a signal handler that enables a
>      breakpoint explicitly

debug_info->suspended_step controls this.

>    * Nested signals

I think nested signals can be dealt correctly because we save state in 
signal frame.

However I'll try the above cases you mentioned above.

Thank you.