<div>Hi everyone,</div><div><br></div><div>This is my first list post, thanks for bearing with me.</div><div><br></div><div>Summary:</div><div>Kernel is compiled with CONFIG_HAVE_HW_BREAKPOINT but after boot the DSCR register does not have monitor mode enabled which is required for debug register use.</div>

<div>Kernel fails to set monitor mode in the initialization for hw breakpoints/watchpoints. </div><div>It appears to be an EPERM which is silently discarded. I think this should be logged as pr_warning and I would also be interested to see why it's failing and fix this.</div>

<div>Any thoughts or suggestions would be greatly appreciated!</div><div><br></div><div>Details:</div><div>I am interested in using the ptrace interface for hw breakpoints/watchpoints on a Cortex A9. I found out that watchpoints are not triggering and tracked down an issue to the hw_breakpoint.c. The flow is as follows:</div>

<div>arch_hw_breakpoint_init > on_each_cpu(reset_ctrl_regs, &cpumask, 1);  > reset_ctrl_regs > enable_monitor_mode</div><div><br></div><div>enable_monitor_mode performs ARM_DBG_WRITE(c2, 2, (dscr | ARM_DSCR_MDBGEN)); </div>

<div>Another read on dscr is performed to check if the bit was set and if not it returns -EPERM. In my case the write is not successful so it returns.</div><div><br></div><div>Since the reset_ctrl_regs code just returns on failure setting the monitor mode, there is no reporting of this.</div>

<div>if (enable_monitor_mode)</div><div> return ret;</div><div><br></div><div>Hardware: OMAP4460 CPU inside a Galaxy Nexus phone.</div><div>Software: Android 4.1.1 and Linux Kernel 3.0.31.</div><div>DSCR reads 0x01030002 before/after enable_monitor_mode showing ARM_DSCR_MDBGEN (bit 15) is not set.</div>

<div>DIDR reads 0x3513702a ( 6 watchpoints and 2 breakpoints )</div><div>PTRACE_GETGBPREGS result = 0x3513702a (debug_arch 0x3, max_wp_length = 4, wp_count = 1, bp_count = 5)</div><div><br></div><div>I am aware that the ptrace in my kernel version reports 1 wp as hardcoded due to an issue with identifying which wp triggered.</div>

<div><br></div><div>dmesg shows the following happening at boot. the hw-wp lines are my own extra pr_info lines to help debug.</div><div><br></div><div><div><6>[    0.515777] hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.</div>

<div><6>[    0.515777] hw-breakpoint: 1 breakpoint(s) reserved for watchpoint single-step.</div><div>// core 1</div><div><6>[    0.516265] hw-breakpoint: hw-wp: reset_ctrl_regs DBGOSLSR = 0x0</div><div><6>[    0.516265] hw-breakpoint: hw-wp: reset_ctrl_regs DBGAUTHSTATUS = 0xaa</div>

<div><6>[    0.516723] hw-breakpoint: hw-wp: enable_monitor_mode entering dscr = 0x1030002...</div><div><6>[    0.516723] hw-breakpoint: hw-wp: enable_monitor_mode setting ARM_DSCR_MDBGEN for ARM_DEBUG_ARCH_V7_ECP14</div>

<div><6>[    0.516998] hw-breakpoint: hw-wp: enable_monitor_mode dscr write failed with EPERM</div><div><6>[    0.517181] hw-breakpoint: hw-wp: enable_monitor_mode leaving dscr = 0x1030002 ret = -1...</div><div>

// core 2: same as above, removed for brevity </div><div><6>[    0.517913] hw-breakpoint: maximum watchpoint size is 4 bytes.</div></div><div><br></div><div>After boot, my ptrace test example with PTRACE_GETHBPREGS works fine but PTRACE_SETHBPREGS fails silently inside arch_install_hw_breakpoint due to the same enable_monitor_mode issue.</div>

<div><br></div>Thanks for your time,<div>Valentin </div>