Messages in this thread |  | | Date | Mon, 18 Nov 2013 14:21:04 +0530 | Subject | Re: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support | From | Sandeepa Prabhu <> |
| |
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) > >> >>> >> 2. 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/
|  |