Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@is.elta.co.il>
To: Orjan Friberg <orjan.friberg@axis.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Hardware watchpoints; dealing with false triggers?
Date: Thu, 29 Nov 2001 07:01:00 -0000	[thread overview]
Message-ID: <Pine.SUN.3.91.1011129164553.14665E-100000@is> (raw)
Message-ID: <20011129070100.g9M3YtdxlaBg9JdTZ_-X-E99aSS0Pw6gb8LHJVPTz6s@z> (raw)
In-Reply-To: <3C064547.93F40E8D@axis.com>

On Thu, 29 Nov 2001, Orjan Friberg wrote:

> I'm wondering how/if gdb deals with false hardware watchpoint triggers. 

In general, there shouldn't be any.  If you have lots of false triggers, 
you will be in trouble, since the higher-level code of GDB cannot cope 
with that very well.

So the low-level watchpoint support should do whatever it takes to
eliminate the possibility of false hits.

> I've looked at the i386 hardware watchpoint implementation in gdb, and
> read chapter 15 of the Intel Architecture Software Developer's Manual
> Volume 3 about the debug registers, but I can't tell if it's susceptible
> to false triggers.

AFAIK, the x86 watchpoint support doesn't cause false triggers, except in 
one case: if you use `rwatch'.  x86 debug support doesn't support 
read-only watchpoints, only read-write or write-only watchpoints.  To 
emulate rwatch, GDB's higher-level code has some kludgey work-arounds (it 
checks whether the value changed or not), which I had hard time 
convincing Michael Snyder to accept, and rightfully so.

> The i386 breakpoint registers can only deal with 1,
> 2, and 4-byte sized areas, so watching a 4-byte aligned 3-byte struct
> seems to use two of the i386's debug registers (watching 2 and 1 bytes,
> respectively).

Yes.

> But consider the following: say your watchpoint registers can only watch
> 4-byte aligned areas of 4 bytes, but you want to rwatch (or awatch) an
> unaligned variable of size 4 bytes.  You'd have to use two watchpoint
> registers, both covering too much, like this:
> 
> Variable to watch:      | 0 1   2 3 |
> Watchpoints:        | 0 1 2 3 | 0 1 2 3 |
>                         wp1       wp2

This shouldn't happen, and it indeed does not happen with x86.  x86 uses 
2 debug registers in this case, like so:

Variable to watch:      | 0 1   2 3 |
Watchpoints:            | 0 1 | 0 1 |
                          wp1   wp2

If the variable is only single-byte aligned, x86 would use 3 debug 
registers to cover it: the first one watching 1 byte, and two others
watching 2 bytes each.

> Now, say a there's a read of wp1's byte 0.  The hardware would trigger,
> but it would be a false trigger.  Gdb would somehow have to find out the
> actual address that was read and if it was found to be outside of the
> variable's range it would not trigger the watchpoint.

You can't do that, at least not with x86 debug registers: when a 
watchpoint triggers, you don't know what byte of its covered memory was 
written to.  All you know is that memory covered by a specific register 
was written.  In other words, the Debug Status register has only one bit 
for each of the 4 debug registers, to tell you which of the registers' 
watchpoints triggered; but it doesn't tell you what bytes were modified.
> are
> there any major obstacles for implementing such target-dependent false
> trigger handling in gdb?

IIRC, no.  If you cannot do something similar to what x86 does, I think 
you are in for a bumpy ride, as GDB doesn't handle such problems very 
well.  Your best bet would be to solve this in the target-specific 
low-level code.

Do you really have such a strange target?  Can you tell the details?


  parent reply	other threads:[~2001-11-29  7:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-29  6:25 Orjan Friberg
2001-11-19 11:58 ` Orjan Friberg
2001-11-19 12:06 ` Eli Zaretskii [this message]
2001-11-29  7:01   ` Eli Zaretskii
2001-11-30  8:44   ` Orjan Friberg
2001-11-21 17:14     ` Orjan Friberg
2001-11-22 13:19     ` Eli Zaretskii
2001-11-30 10:33       ` Eli Zaretskii
2001-12-04  3:09       ` Orjan Friberg
2001-12-04  3:43         ` Eli Zaretskii
2001-12-04  5:51           ` Orjan Friberg

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=Pine.SUN.3.91.1011129164553.14665E-100000@is \
    --to=eliz@is.elta.co.il \
    --cc=gdb-patches@sources.redhat.com \
    --cc=orjan.friberg@axis.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