From: Eli Zaretskii <eliz@gnu.org>
To: "Pierre Muller" <muller@ics.u-strasbg.fr>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA] Fix a windows bug if two watchpoints are used
Date: Thu, 04 Jun 2009 03:16:00 -0000 [thread overview]
Message-ID: <E1MC3RX-0003Di-Hj@fencepost.gnu.org> (raw)
In-Reply-To: <000601c9e4a3$b2f2f980$18d8ec80$@u-strasbg.fr> (muller@ics.u-strasbg.fr)
> From: "Pierre Muller" <muller@ics.u-strasbg.fr>
> Cc: <gdb-patches@sourceware.org>
> Date: Thu, 4 Jun 2009 01:33:27 +0200
> Content-Language: en-us
>
> > Shouldn't we instead fix the logic of i386_stopped_data_address, to
> > get out of the loop on the first watchpoint that is found to be hit?
> > The function does not support more than one watchpoint anyway, so why
> > continue checking the bits in dr[6] after we've found one set already?
> >
> > Would such a change fix your problem without the other complications?
>
> It would hide the problem.
Why hide, and what problem are we talking about? The situation you
describe has no rational explanation, and looks more like a Windows
bug than anything else: you in effect show a contradiction between two
debug registers that should tell a coherent story, but don't. Fixing
such problems without a good understanding of their exact reasons is
always a bit phenomenological. My phenomenology is based on the
premise that the OS uses the debug registers in the order we scan the
bits in dr[6], so the first one we find set has better chances to be
consistent with what really happened than anything else.
> But what happens if you have different watchpoints
> on the same address (say one 'watch' and one 'awatch')?
> Are you sure your suggestion would not affect
> such cases?
It will work even in those cases, yes. We only support multiple
watchpoints that break simultaneously if they watch the same address,
anyway (there's only one address that i386_stopped_data_address
returns). The i386 debug register support code will use a single
debug register for watching such an address, no matter how many
watchpoints the user sets and of what kind. We do this sharing of
debug registers entirely in GDB (see i386_insert_aligned_watchpoint
and the dr_ref_count[] array it uses); the OS is never told to use
more than one debug register for every address we watch, even if we
watch it with several watchpoints. The callers of
i386_stopped_data_address take the address it returns, and check all
the watchpoints that watch this address to see which one(s) of them
triggered and which did not. That code is in breakpoint.c, AFAIR.
> > Btw, I don't understand this part of i386_stopped_data_address:
> >
> > if (maint_show_dr && addr == 0)
> > i386_show_dr ("stopped_data_addr", 0, 0, hw_write);
> >
> > Isn't that backwards? why display the address if it is zero?
> I think this is because if addr is non-zero, you already
> have a call to i386_show_dr before with "watchpoint hit".
> This call is simply to state that stopped_data_address
> was called but didn't find a hit.
> But the correct condition should be (rc == 0) instead
> of (addr == 0) as setting a watchpoint at (CORE_ADDR) 0
> should also work on target where this address is not protected.
Yes, I agree.
next prev parent reply other threads:[~2009-06-04 3:16 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-03 22:58 Pierre Muller
2009-06-03 23:21 ` Eli Zaretskii
2009-06-03 23:33 ` Pierre Muller
2009-06-04 3:16 ` Eli Zaretskii [this message]
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
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=E1MC3RX-0003Di-Hj@fencepost.gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=muller@ics.u-strasbg.fr \
/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