[lkml]   [2016]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2] arm64: Store breakpoint single step state into pstate

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.


> 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

> 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.

 \ /
  Last update: 2016-01-05 03:01    [W:0.080 / U:41.984 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site