public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Phil Muldoon <pmuldoon@redhat.com>
Cc: Frysk Hackers <frysk@sourceware.org>
Subject: Re: Optimizing watchpoints
Date: Sun, 30 Sep 2007 19:10:00 -0000	[thread overview]
Message-ID: <1191179433.3275.14.camel@hermans.wildebeest.org> (raw)
In-Reply-To: <46FD7036.2010500@redhat.com>

Hi Phil,

On Fri, 2007-09-28 at 22:20 +0100, Phil Muldoon wrote:
> Given that debug registers are very scarce, and that typically there 
> might be a scenario where we could better optimize watching similar 
> addresses and ranges, is there an established protocol for this?
> 
> I thought about checking addresses and ranges as a simple "we are 
> already watching this address in another register and scope". But as 
> usual things get hairy in C when you add in pointers (that pointer to 
> pointers in structures and so on).

We are already doing a simple version of this for low level breakpoints.
For each Code observer added at the proc level there is a simple map,
BreakpointAddresses, that keeps track of whether or not an actual
breakpoint instruction is already there. So whenever a Code observer is
added or removed at a particular address the BreakpointAddresses map is
consulted to see whether an existing one can be reused, or should be
kept, because other Code observers are monitoring the address.

For watchpoints you don't just have simple addresses, but also a range.
That makes your 'overlapping' detection a little less straightforward
than in the Code observer case. But BreakpointAddresses does already
give a simple version that can find breakpoint addressses given a range
of memory, public Iterator getBreakpoints(long from, long till).
Something like this, based on a TreeSet of addresses plus ranges can
probably be used to implement your watchpoint address range overlapping
detection.

I wouldn't worry too much about the particulars of hairy C structures.
That should be handled at a higher language level by installing multiple
proc watchpoint observers.

Cheers,

Mark

  reply	other threads:[~2007-09-30 19:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-28 21:21 Phil Muldoon
2007-09-30 19:10 ` Mark Wielaard [this message]
2007-10-01  1:25 ` Roland McGrath
2007-10-01  8:41   ` Mark Wielaard
2007-10-01  9:11     ` Phil Muldoon
2007-10-01  9:20       ` Mark Wielaard
2007-10-01 17:40     ` Roland McGrath
2007-10-01 17:54   ` Phil Muldoon
2007-10-10  7:11   ` Phil Muldoon
2007-10-10 10:28     ` Mark Wielaard

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=1191179433.3275.14.camel@hermans.wildebeest.org \
    --to=mark@klomp.org \
    --cc=frysk@sourceware.org \
    --cc=pmuldoon@redhat.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).