This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA 2] Debug register support in win32-nat.c (need opinions)
- From: Eli Zaretskii <eliz at is dot elta dot co dot il>
- To: Christopher Faylor <cgf at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 14 Jan 2002 10:14:49 +0200 (IST)
- Subject: Re: [RFA 2] Debug register support in win32-nat.c (need opinions)
On Sun, 13 Jan 2002, Christopher Faylor wrote:
> >I agree that the linux implementation does not set the debug registers
> >for all threads but this means that if a watched expression is modified
> >by another thread than the current thread at the time of setting the
> >watchpoint will not be caught and that is much worse...
>
> You described this in your original email. I should have responded to
> it.
>
> I don't think it makes sense to make gratuitous changes to the way gdb
> works. If you're implementing an improvement for gdb for Windows then
> I think it should probably work the same way for Windows as it does
> for linux.
>
> I guess I need a ruling from more experienced maintainers about this.
>
> How should gdb behave in this scenario?
I'm not an expert, so this is FWIW:
The basic assumption behind the generic x86 watchpoint code in
i386-nat.c is that the watchpoints are not thread-specific. That's
why i386-nat.c stores the info in a single array that doesn't have
thread information, and that's why the I386_DR_LOW_* macros don't
accept a thread id as an argument.
IIRC, this issue was discussed back when I published the first draft
of the watchpoint API, and the general consensus was that I shouldn't
bother about thread-specific watchpoints. You may wish to reread that
discussion (I can dig out a pointer to it if you cannot find it.)
I also agree with Pierre that global watchpoints are much better than
thread-local ones. For starters, you can always write a condition for
a global watchpoint that lets the debuggee continue if the thread id
is not what you want; but pulling the reverse trick with thread-local
watchpoints is impossible.
So if indeed GNU/Linux versions of GDB set watchpoints on a per thread
basis (I'm surprised they do), I think that's a misfeature, to say the
least.