Hello Will,
Hi Ulrich,
I've been trying to get GDB support for hardware watchpoints/breakpoints going. I've ported Matthew's GDB patch to current mainline, and am running this under a 2.6.37-1002-linaro-omap kernel on an IGEPv2 board.
Great - it's nice to see somebody using this stuff!
However, something seems to be not quite working: I'm seeing this kernel message on boot: hw-breakpoint: debug architecture 0x4 unsupported. and then at runtime, the result of a PTRACE_GETHBPREGS call for register 0 is 0x04000106: debug architecture: 4 watchpoint size: 0 nr. watchpoints: 1 nr. breakpoints: 6
This leads me to a couple of questions:
- It seems odd that the kernel says it doesn't support the debug
architecture, but then reports to user space that 1 watchpoint and 6 breakpoints are supported ... GDB will never use the watchpoint, because the maximum watchpoint size is reported as zero, but GDB will attempt to use the breakpoints. Setting a breakpoint will appear to succeed, but then the breakpoint just never triggers. The kernel should IMO be more consistent in how unsupported configurations are handled ...
Agreed. This is an artifact of how the ptrace info register is populated. I'll work on a fix tomorrow so that we don't report any resources when the architecture is unsupported.
- Why is architecture 0x4 not supported? This seems to be the variant of
the v7 debug architecture with memory-mapped registers. Apparently the IGEP only supports this version ... Do you know what the Beagle-/Pandaboard and other clones do? What would it take to support this architecture variant? Given the widespread use of those boards, it would be really nice if we could support hardware debugging on them ...
The memory-mapped interface is hugely unreliable in real hardware because you have to calculate the address of the memory-mapped debug registers by using a base and offset, which are hardcoded in some information registers. Unfortunately, I've never found a board where these registers have been programmed correctly so (a) I had nothing to test my code with (b) few people would be able to use it and (c) there's not really a safe way to go around poking random areas of memory.
- Which hardware *is* supported? Can you recommend a board I should be
using to verify GDB support is working?
The simple rule is Cortex-A8 is unsupported and Cortex-A9 is supported. The A5 should work (untested) and the A15 will need a bit of hacking to get it supported.
Thanks for your help in getting this working!
No problem. If you find anybody with working memory-mapped debug and some spare time, I'd be happy to review patches :)
I'll CC you on a fix for the ptrace info register.
Will