Subject: watch exception only for kseg0 addresses..?

From: "atul srivastava" <[email-masked]>
Date: 25 Nov 2002 07:52:38 -0000

Hello,

I am trying to set a watch exception in (IDT RC32334) my debugging 
execise
In arch/mips/lib/watch.S says "curremtly available only for KSEG0 
address"

which is evident by following assembly..
                 LEAF(__watch_set)
                 li      t0,0x80000000
                 subu    a0,t0
                 ori     a0,7
                 xori    a0,7
                 or      a0,a1
                 mtc0    a0,CP0_WATCHLO
                 .......

it is loading the physical address of KSEG0 addresses in CP0 
watchpoint register.

in change history of this file i am able to see  KSEG0 restriction 
removed only for arch/mips64/lib/watch.S...

while my manual is not specific about KSEG0 , can i safely use it 
for all addresses ,offcourse then above assembly has to be 
modified appropiately for addresses of different regions..

Best Regards.
Ashish

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 25 Nov 2002 10:24:59 +0100

> it is loading the physical address of KSEG0 addresses in CP0 

Additional problem - I know of at least one CPU on which the watch register
does not work for KSEG0 but only for TLB mapped registers.  That CPU
doesn't document this behaviour btw.

> removed only for arch/mips64/lib/watch.S...

The hw takes physical addresses, so using a a virtual address as argument
for __watch_set seemed to be stupid anyway.  The hw takes a physical
address and the conversion is best done in C anyway.

> modified appropiately for addresses of different regions..

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

  Ralf

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 25 Nov 2002 12:55:11 +0100 (MET)

> 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).

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 25 Nov 2002 13:18:07 +0100

> single-steps code which sucks performace-wise).

Agreed.  And because such an extension would be fully backward compatible
introduction is no problem.  So time to come up with a reasonable API.
MIPS32 / MIPS64 extend the R4000's watch capabilities significantly,
something we don't want to ignore.

  Ralf

---

From: Daniel Jacobowitz <[email-masked]>
Date: Mon, 25 Nov 2002 09:40:59 -0500

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 25 Nov 2002 16:08:00 +0100

> 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

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 25 Nov 2002 16:30:13 +0100 (MET)

> watchpoints but they don't require hardware support either, just an

 As a fallback the approach is just fine, but doesn't is suck
performance-wise for watchpoints at the stack?  It certainly sucks for
instruction fetches.  While gdb doesn't seem to use hardware breakpoints
as they are only really necessary for ROMs, other software may want to
(well, gdb too, one day). 

> to adding new PTRACE_* ops.

 Sure, as long as common sense is applied.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 25 Nov 2002 16:47:33 +0100 (MET)

> support anywhere from 0 to 4 such watch registers.

 Actually up to eight -- for all dmfc0/dmtc0 3-bit "sel" values, if I read
it correctly.

> just per thread though I doubt there is much use for something like that.

 Well, there are two options only -- either use global matching or ASID
matching.  What else would you expect?  Do you mean lazy vs immediate
switching?