Re: watch exception only for kseg0 addresses..?

[Ralf Baechle <ralf@linux-mips.org>]

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