This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Fix a windows bug if two watchpoints are used
On Wed, Jun 03, 2009 at 11:16:39PM -0400, Eli Zaretskii wrote:
>Pierre Muller wrote:
>>>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.
FWIW, I agree with Eli's assessments here.
cgf