[Top] [All Lists]

Re: watch exception only for kseg0 addresses..?

To: "Maciej W. Rozycki" <>
Subject: Re: watch exception only for kseg0 addresses..?
From: Daniel Jacobowitz <>
Date: Wed, 11 Dec 2002 13:01:35 -0500
Cc: Ralf Baechle <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <>
User-agent: Mutt/1.5.1i
On Wed, Dec 11, 2002 at 06:38:51PM +0100, Maciej W. Rozycki wrote:
> On Wed, 11 Dec 2002, Daniel Jacobowitz wrote:
> > That way we expose more of the hardware to userland; and the thing
> > that's most important to me is that GDB not have to know if it's on a
> > MIPS32 or an R4650 when determining how watchpoints work. 
> > IWatch/DWatch are two particular watchpoints or distinguished by access
> > type?  I.E. what would GDB need to know to know which it is setting?
>  The watchpoints would always be interfaced the same way, regardless of
> the underlying implementation, of course.  For the IWatch/DWatch, I'd
> assign their numbers somehow (e.g. IWatch is watchpoint #0 and DWatch is
> #1, following the sequence used for their CP0 register numbers).  A user
> such as GDB would have to determine the capabilities of all watchpoints as
> I described and would discover that watchpoint #0 only accepts instruction
> fetch events and watchpoint #1 only accepts data read/write ones.
>  This way we can accept an arbitrary underlying implementation.

This is what I don't like.  Setting each individual watchpoint to
determine their capabilities, when the kernel could just _report_ said
capabilities.  It's a difference in philosophy I suppose.  I also have
some concerns about making the probing indistinguishable from setting a
watchpoint; if MIPS37 or MPIS256 has a substantially different
watchpoint layout, we'll have to give it a whole new set of ptrace ops,
which defeats the point of abstracting it.

If we write up decent documentation for what a userspace implementation
has to do to probe the current implementations, I guess I'm satisfied.

Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

<Prev in Thread] Current Thread [Next in Thread>