fdfeff0f9e
Arm64 hardware does not always report a watchpoint hit address that matches one of the watchpoints set. It can also report an address "near" the watchpoint if a single instruction access both watched and unwatched addresses. There is no straight-forward way, short of disassembling the offending instruction, to map that address back to the watchpoint. Previously, when the hardware reported a watchpoint hit on an address that did not match our watchpoint (this happens in case of instructions which access large chunks of memory such as "stp") the process would enter a loop where we would be continually resuming it (because we did not recognise that watchpoint hit) and it would keep hitting the watchpoint again and again. The tracing process would never get notified of the watchpoint hit. This commit fixes the problem by looking at the watchpoints near the address reported by the hardware. If the address does not exactly match one of the watchpoints we have set, it attributes the hit to the nearest watchpoint we have. This heuristic is a bit dodgy, but I don't think we can do much more, given the hardware limitations. Signed-off-by: Pavel Labath <labath@google.com> [panand: reworked to rebase on his patches] Signed-off-by: Pratyush Anand <panand@redhat.com> [will: use __ffs instead of ffs - 1] Signed-off-by: Will Deacon <will.deacon@arm.com> |
||
|---|---|---|
| .. | ||
| boot | ||
| configs | ||
| crypto | ||
| include | ||
| kernel | ||
| kvm | ||
| lib | ||
| mm | ||
| net | ||
| xen | ||
| Kconfig | ||
| Kconfig.debug | ||
| Kconfig.platforms | ||
| Makefile | ||