All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.