Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: kettenis@gnu.org, jjohnstn@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: [RFA]: Modified Watchthreads Patch
Date: Sat, 11 Dec 2004 17:53:00 -0000	[thread overview]
Message-ID: <20041211173757.GB15506@nevyn.them.org> (raw)
In-Reply-To: <01c4dfa6$Blat.v2.2.2$d4763ba0@zahav.net.il>

On Sat, Dec 11, 2004 at 07:27:26PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 11 Dec 2004 11:36:52 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: eliz@gnu.org, jjohnstn@redhat.com, gdb-patches@sources.redhat.com
> > 
> > The kernel implementation of hardware watchpoints is very
> > platform-dependent because the hardware implementation of hardware
> > watchpoints is very platform-dependent.
> 
> ??? Are we still talking about x86?  If so, there are only 2 possible
> mechanisms I know about: (1) debug registers and (2) page-level
> protection.  Are there any others?  Am I missing something?

No, sorry.  Mark made general comments about "Linux" so that's what I
was responding to.

The range of implementations of MIPS hardware watchpoints, for
instance, are somewhat different than the i386 ones.  You've got the
same two options (that is, if your platform has appropriate debug
registers), but the features offered by the debug registers can vary. 
So can their globalness.  For instance, a platform which only placed
watchpoints on physical addresses instead of virtual addresses would
probably not offer thread-specific setting of the watchpoint registers.
[Do any platforms do that, and also support SMP?  I sure hope not.]

> > I would expect that they would always be
> > per-thread on any Linux target with true hardware watchpoints.  Of
> > course, they'll be process global if they're implemented by page
> > protections
> 
> The implementation that uses debug registers can be either global or
> local, depending on some bit in one of the registers.  One thing GDB
> should know about a platform is how that platform fiddles with that
> bit.

For the Linux kernel, it doesn't matter what you set in that bit.  It
has to clear the registers at task switch anyway, for security reasons.
I imagine this is true on most other protected, multi-tasking OS's
also; am I missing something?

-- 
Daniel Jacobowitz


  reply	other threads:[~2004-12-11 17:38 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-10  4:24 Jeff Johnston
2004-12-10 13:31 ` Eli Zaretskii
2004-12-10 14:21   ` Daniel Jacobowitz
2004-12-10 18:01     ` Jeff Johnston
2004-12-24 11:05       ` Michael Snyder
2005-01-07  0:23         ` jjohnstn
2004-12-10 23:01     ` Eli Zaretskii
2004-12-10 23:31       ` Daniel Jacobowitz
2004-12-10 19:10   ` Jeff Johnston
2004-12-10 22:51     ` Eli Zaretskii
2004-12-23 22:32   ` Michael Snyder
2004-12-24 14:46     ` Eli Zaretskii
2004-12-10 20:03 ` Daniel Jacobowitz
2004-12-10 20:30   ` Jeff Johnston
2004-12-10 20:47     ` Daniel Jacobowitz
2004-12-10 22:18       ` Jeff Johnston
2004-12-10 23:57         ` Jeff Johnston
2004-12-11  0:31           ` Daniel Jacobowitz
2004-12-11  1:28             ` Jeff Johnston
2004-12-11 14:34           ` Eli Zaretskii
2004-12-11 16:56             ` Daniel Jacobowitz
2004-12-11 18:01               ` Eli Zaretskii
2004-12-11 18:06                 ` Daniel Jacobowitz
2004-12-11 19:08                   ` Eli Zaretskii
2004-12-11 19:30                     ` Daniel Jacobowitz
2004-12-12  5:22                       ` Eli Zaretskii
2004-12-11 21:54                   ` Mark Kettenis
2004-12-11 14:53           ` Mark Kettenis
2004-12-11 16:52             ` Eli Zaretskii
2004-12-11  2:04       ` Daniel Jacobowitz
2004-12-11 16:11         ` Mark Kettenis
2004-12-10 23:06   ` Eli Zaretskii
2004-12-10 23:10     ` Daniel Jacobowitz
2004-12-10 23:37       ` Eli Zaretskii
2004-12-10 23:52         ` Daniel Jacobowitz
2004-12-11 11:32           ` Eli Zaretskii
2004-12-11 14:49             ` Mark Kettenis
2004-12-11 16:48               ` Daniel Jacobowitz
2004-12-11 17:33                 ` Eli Zaretskii
2004-12-11 17:53                   ` Daniel Jacobowitz [this message]
2004-12-11 18:07                     ` Eli Zaretskii
2004-12-11 18:50                       ` Daniel Jacobowitz
2004-12-11 19:06                 ` Mark Kettenis
2004-12-11 19:07                   ` Daniel Jacobowitz
2004-12-11 16:49               ` Eli Zaretskii
2004-12-11 16:37             ` Daniel Jacobowitz
2004-12-11 17:30               ` Eli Zaretskii
2004-12-11 17:38                 ` Daniel Jacobowitz
2004-12-11 18:02                   ` Eli Zaretskii
2004-12-11 18:10                     ` Daniel Jacobowitz
2005-01-13 19:22                   ` Jeff Johnston
2005-02-11  1:57                     ` Daniel Jacobowitz
2005-02-11 18:18                       ` Eli Zaretskii
2005-02-11 18:31                         ` Daniel Jacobowitz
2005-02-12 21:50                           ` Eli Zaretskii
2004-12-11 19:35 Ulrich Weigand

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=20041211173757.GB15506@nevyn.them.org \
    --to=drow@false.org \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jjohnstn@redhat.com \
    --cc=kettenis@gnu.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