From: "Pierre Muller" <muller@ics.u-strasbg.fr>
To: "'Eli Zaretskii'" <eliz@gnu.org>
Cc: <gdb-patches@sourceware.org>
Subject: RE: [RFA-v2] Fix a windows bug if two watchpoints are used
Date: Thu, 04 Jun 2009 14:52:00 -0000 [thread overview]
Message-ID: <001501c9e523$feffc1c0$fcff4540$@u-strasbg.fr> (raw)
In-Reply-To: <E1MCAEM-0005ix-2I@fencepost.gnu.org>
> > My problem is indeed fixed without that part,
> > but without my change to I386_DR_DISABLE, the second check
> > in i386_stopped_data_address:
> >
> > ALL_DEBUG_REGISTERS(i)
> > {
> > if (I386_DR_WATCH_HIT (i)
> > /* This second condition makes sure DRi is set up for a data
> > watchpoint, not a hardware breakpoint. The reason is
> > that GDB doesn't call the target_stopped_data_address
> > method except for data watchpoints. In other words, I'm
> > being paranoiac. */
> > && I386_DR_GET_RW_LEN (i) != 0)
> >
> > is not reliable as the return value of I386_DR_GET_RW_LEN (i)
> > is non-zero if I was used before... Even if it was disabled
> > later!
>
> This is C: if the result of the first test is false, the result of the
> second test is not important, right?
>
> Or am I missing something?
If all works fine, there is no problem, you are right,
but otherwise...
If, like for my cygwin problem,
dr_status_mirror has both bits 1 and 2 set
while only the first debug register is used according
to previous calls of the i386-nat functions.
This is probably an OS problem, but the whole thread is related to that...
In that situation, the second test, which is supposed to check if indeed
we have
that second register used as a hardware watchpoint, and not a
hardware breakpoint, according to the comment, fails.
Maybe we should use
ALL_DEBUG_REGISTERS(i)
{
if (I386_DR_WATCH_HIT (i)
&& !I386_DR_VACANT(i)
&& I386_DR_GET_RW_LEN (i) != 0)
In that case, I think that the code should be fine even if
the underlying OS reports a spurious bit of the debug status register as
set.
Pierre
next prev parent reply other threads:[~2009-06-04 14:52 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-03 22:58 [RFA] " Pierre Muller
2009-06-03 23:21 ` Eli Zaretskii
2009-06-03 23:33 ` Pierre Muller
2009-06-04 3:16 ` Eli Zaretskii
2009-06-04 3:29 ` Christopher Faylor
2009-06-04 6:34 ` [RFA-v2] " Pierre Muller
2009-06-04 7:12 ` Eli Zaretskii
2009-06-04 7:33 ` Pierre Muller
2009-06-04 10:31 ` Eli Zaretskii
2009-06-04 14:52 ` Pierre Muller [this message]
2009-06-04 15:22 ` Eli Zaretskii
2009-06-16 22:43 ` [PING][RFA-v2] " Pierre Muller
2009-06-22 20:56 ` Joel Brobecker
2009-06-23 1:04 ` Eli Zaretskii
2009-09-22 12:55 ` [RFA-v3] " Pierre Muller
2009-09-24 3:04 ` Eli Zaretskii
2009-09-24 17:54 ` Joel Brobecker
2009-09-24 22:08 ` Pierre Muller
2009-09-25 1:53 ` Joel Brobecker
2009-09-25 15:32 ` Pierre Muller
2009-09-25 16:07 ` Joel Brobecker
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='001501c9e523$feffc1c0$fcff4540$@u-strasbg.fr' \
--to=muller@ics.u-strasbg.fr \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.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