From: "Pierre Muller" <muller@ics.u-strasbg.fr>
To: <gdb-patches@sourceware.org>
Cc: <mlluber@gmx.de>
Subject: [RFA] win32-nat.c: Fix for bug report gdb/2388
Date: Fri, 21 Dec 2007 14:31:00 -0000 [thread overview]
Message-ID: <007101c843d9$ef5023b0$cdf06b10$@u-strasbg.fr> (raw)
I examined the bug report gdb/2388
Go to:
http://sourceware.org/cgi-bin/gnatsweb.pl
and enter number 2388
I think that this is a bug that I introduced when I first wrote
the cygwin hardware watchpoint support a while ago.
The problem is that there is a common
dr array that keeps track of the values of
all the debug registers, while, on Win32 API,
each thread has its own copy of those registers.
The only possible pitfall is if the program itself
changes the debug registers (I do not know if this is
possible, without generating a exception).
The dr[6] status register, that might indicate that
we did trigger a watchpoint, is anyhow set at the moment
As long as we only use the same copy of dr array for
all the threads, I think that the patch below should
fix the reported bug.
The patch simply does not overwrite dr array is
debug_registers_changed is set, which happens if
the i386 debug registers are changed.
I tested the patch, and the SIGTRAP reported
in the bug report is suppressed by my patch.
I also ran the testsuite with no regressions.
OK to commit?
Pierre Muller
ChangeLog entry:
2007-12-21 Pierre Muller <muller@ics.u-strasbg.fr>
* win32-nat.c: Fix PR/2388.
(do_win32_fetch_inferior_registers): Do not overwrite debug register
array dr if debug_registers_changed variable is set.
Index: gdb/win32-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/win32-nat.c,v
retrieving revision 1.143
diff -u -p -r1.143 win32-nat.c
--- gdb/win32-nat.c 6 Dec 2007 11:17:03 -0000 1.143
+++ gdb/win32-nat.c 20 Dec 2007 15:11:42 -0000
@@ -382,13 +382,17 @@ do_win32_fetch_inferior_registers (struc
thread_info *th = current_thread;
th->context.ContextFlags = CONTEXT_DEBUGGER_DR;
GetThreadContext (th->h, &th->context);
- /* Copy dr values from that thread. */
- dr[0] = th->context.Dr0;
- dr[1] = th->context.Dr1;
- dr[2] = th->context.Dr2;
- dr[3] = th->context.Dr3;
- dr[6] = th->context.Dr6;
- dr[7] = th->context.Dr7;
+ /* Copy dr values from that thread.
+ But only if there were not modified since last stop. PR
gdb/2388 */
+ if (!debug_registers_changed)
+ {
+ dr[0] = th->context.Dr0;
+ dr[1] = th->context.Dr1;
+ dr[2] = th->context.Dr2;
+ dr[3] = th->context.Dr3;
+ dr[6] = th->context.Dr6;
+ dr[7] = th->context.Dr7;
+ }
}
current_thread->reload_context = 0;
}
next reply other threads:[~2007-12-21 14:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-21 14:31 Pierre Muller [this message]
2007-12-21 17:20 ` Christopher Faylor
2007-12-23 5:36 ` Pierre Muller
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='007101c843d9$ef5023b0$cdf06b10$@u-strasbg.fr' \
--to=muller@ics.u-strasbg.fr \
--cc=gdb-patches@sourceware.org \
--cc=mlluber@gmx.de \
/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