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.
MontaVista Software Debian GNU/Linux Developer