Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <dan@debian.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: watch exception only for kseg0 addresses..?
Date: Wed, 11 Dec 2002 13:01:35 -0500	[thread overview]
Message-ID: <20021211180135.GB14768@nevyn.them.org> (raw)
In-Reply-To: <Pine.GSO.3.96.1021211182901.22157N-100000@delta.ds2.pg.gda.pl>

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

  reply	other threads:[~2002-12-11 18:01 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-25  7:52 watch exception only for kseg0 addresses..? atul srivastava
2002-11-25  9:24 ` Ralf Baechle
2002-11-25 11:55   ` Maciej W. Rozycki
2002-11-25 12:18     ` Ralf Baechle
2002-11-25 14:40     ` Daniel Jacobowitz
2002-11-25 15:08       ` Ralf Baechle
2002-11-25 15:47         ` Maciej W. Rozycki
2002-12-04  0:37           ` Ralf Baechle
2002-12-04  0:58             ` Daniel Jacobowitz
2002-12-04 15:48             ` Maciej W. Rozycki
2002-11-25 15:30       ` Maciej W. Rozycki
2002-12-04  0:15         ` Daniel Jacobowitz
2002-12-04 15:45           ` Maciej W. Rozycki
2002-12-04 15:51             ` Daniel Jacobowitz
2002-12-04 17:54               ` Maciej W. Rozycki
2002-12-11 16:58                 ` Daniel Jacobowitz
2002-12-11 17:38                   ` Maciej W. Rozycki
2002-12-11 18:01                     ` Daniel Jacobowitz [this message]
2002-12-12 11:15                       ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021211180135.GB14768@nevyn.them.org \
    --to=dan@debian.org \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@ds2.pg.gda.pl \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox