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
> 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
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?