On 13 November 2013 20:01, Will Deacon <will.dea...@arm.com> wrote: > On Wed, Nov 13, 2013 at 06:55:33AM +0000, Sandeepa Prabhu wrote: >> >>> I'm unsure about arm64's debug feature behavior, what does happen when >> >>> it performs a single-step on sw-breakpoint? >> >>> >> >>>> Sandeepa: I think you need to retry Masami's test on the arm64 model, >> >>>> since >> >>>> I'm fairly sure it won't work as expected without some additional code. >> >>> >> >>> OK, anyway, for testing same one, we need to port ftrace first. So the >> >>> next >> > >> > Sorry for confusion, s/next/fallback is what I meant. Making a kprobe >> > module >> > can be done without ftrace port. >> > >> >>> plan is to make a kprobe module to put a probe (which just printk >> >>> something) >> >>> on a specific function (e.g. vfs_symlink), and run perf record with >> >>> hw-breakpoint as below >> >>> >> >>> $ perf record -e "mem:0xXXXXXX:k" ln -s /dev/null /tmp/foo >> >>> >> >>> Note that 0xXXXXXX is the address of vfs_symlink. >> >>> >> >>> After that, you can see the message in dmesg and also check the perf >> >>> result >> >>> with "sudo perf script --dump" (you can find a PERF_RECORD_SAMPLE entry >> >>> if >> >>> it works) >> Hi Will, Masami, >> >> I am not sure of 'perf' right now (my minimal rootfs doesn't have) but >> I tried to test hardware breakpoints using sample modules >> "samples/hw_breakpoint/" on arm64 upstream branch. This should use >> same kernel api as perf I believe. >> >> 1. Placing watchpoint ( attr.bp_type = HW_BREAKPOINT_W | >> HW_BREAKPOINT_R) upon vfs_symlink symbol, but seems watch-point is not >> triggering at all. > > vfs_symlink is a function. Why would you expect to write it? 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.
> >> 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? 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? ~Sandeepa > > Will > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
