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?
next prev 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