Re: [RFA 2] Debug register support in win32-nat.c (need opinions)

[Eli Zaretskii <eliz at is dot elta dot co dot il>]

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.