On Mon, Nov 25, 2002 at 09:40:59AM -0500, Daniel Jacobowitz wrote: > > > The whole watch stuff in the the kernel is pretty much an ad-hoc API > > > which I did create to debug a stack overflow. I'm sure if you're > > > going to use it you'll find problems. For userspace for example you'd > > > have to switch the watch register when switching the MMU context so > > > each process gets it's own virtual watch register. Beyond that there > > > are at least two different formats of watch registers implemented in > > > actual silicon, the original R4000-style and the MIPS32/MIPS64 style > > > watch registers and the kernel's watch code only know the R4000 style > > > one. So check your CPU's manual ... > > > > I think the best use of the watch exception would be making it available > > to userland via PTRACE_PEEKUSR and PTRACE_POKEUSR for hardware watchpoint > > support (e.g. for gdb). Hardware support is absolutely necessary for > > watching read accesses and much beneficial for write ones (otherwise gdb > > single-steps code which sucks performace-wise). > > (Although that isn't necessary; page-protection watchpoints are on my > TODO for next year. They aren't quite as efficient as hardware > watchpoints but they don't require hardware support either, just an > MMU.) > > Heck, you can even do read watchpoints that way. > > In any case, yes, the thing to do is choose an API for these and expose > them via ptrace; not necessarily in PEEKUSER though. There's no cost > to adding new PTRACE_* ops. I assume you got and R4000 manual and the MIPS64 spec. R4000 implements matching a physical address with a granularity of 8 bytes for load and store operations. MIPS64 extends that to also support instruction address matches; the granularity can be set anywhere from 8 bytes to 4kB; in addition ASID matching and a global bit can be used for matching. A MIPS64 CPU can support anywhere from 0 to 4 such watch registers. The global bit stuff would only be useful for in-kernel use, I think. The ASID thing could be used to implement watchpoints for an entire process, not just per thread though I doubt there is much use for something like that. So how would a prefered ptrace(2) API for hardware watchpoints look like? Ralf
