On 18 November 2013 12:25, Sandeepa Prabhu sandeepa.prabhu@linaro.org wrote:
This is generic test module (samples/hw_breakpoint/data_breakpoint.ko) which places watchpoint for bothe read/write. Atleast watchpt should have triggered for Read right? I also tried with othe functions like do_fork, vfs_read etc but no hit.
You'd need to place something for exec if you want to see anything on the instruction side. A read by the instruction fetcher does not trigger a read watchpoint on ARM.
Hmm, then watchpoint cannot not be placed on text address (instruction fetch path) right? (Sorry I did not check debug spec fully for watchpoint/hw breakpoints, I should do that)
- Placing text breakpoint (modified sample module with attr.bp_type
= HW_BREAKPOINT_X) upon vfs_symlink, and run "ln -s /dev/null /tmp/foo". This time, breakpoint hit but exception is re-cursing infinitely!
The problem here is that we expect the overflow handler to deal with the stepping (like GDB does via ptrace). If you don't register a handler, the kernel will do the step (like you would get if you used perf stat -e mem:0xNNNN:x).
[This test was done on upstream branch, without kprobes patches.] Hmm, then this is expected with test breakpoint right? is this handling to be done by perf and ptrace?
perf stat doesn't register an overflow handler, so the hw_breakpoint backend will handle the step. ptrace registers a handler which sends a SIGTRAP to the debugger (e.g. gdb), which handles the step manually (probably using a PTRACE_SINGLESTEP request).
I did not see arm64 support in linux/tools/perf/, there are multiple patches in mailing list though. Are you aware of any version of perf that work with arm64?
The perf tool should work fine on arm64 using mainline. Are you seeing problems?
Hmm basically perf is working and I can run tests now.
Hi Will, Okay. I can see what you meant with respect to D-flag unmasking, on original patchset(v2). :)
a. Placed a kprobe on vfs_read - works fine independently. b. Placed hw_breakpoint on vfs_read using perf (perf record -e mem:0xffffffc000134ba4:x -a -- sleep 10) and it works fine independently.
c. Now, a+b, first placed kprobe on vfs_read and then ran perf record event on vfs_read (hw breakpoint). Now, seeing that kprobe single step is never complete/never disabled!, so debug exception would generate forever! (Continuously printing "Unexpected kernel single-step exception at EL1")
kprobe pre_handler: p->addr = 0xffffffc000134ba4 reenter_dbg: test API invoked kprobe post_handler: p->addr = 0xffffffc000134ba4 fmp/fo^[[5Dreenter_dbg: test API invoked kprobe pre_handler: p->addr = 0xffffffc000134ba4 Unexpected kernel single-step exception at EL1 Unexpected kernel single-step exception at EL1 ....
Once I change the location of D-flag manipulation (your suggestion) and run enough tests, I would come back with more details and inputs.
Thanks, Sandeepa
Will
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/