This is the mail archive of the
mailing list for the GDB project.
Re: [RFA 2] Debug register support in win32-nat.c (need opinions)
- From: Pierre Muller <muller at cerbere dot u-strasbg dot fr>
- To: gdb-patches at sources dot redhat dot com
- Date: Mon, 14 Jan 2002 09:33:27 +0100
- Subject: Re: [RFA 2] Debug register support in win32-nat.c (need opinions)
- References: <20020114015821.GA1584@redhat.com>
At 09:14 14/01/2002 , Eli Zaretskii a écrit:
>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.
Anyway, it is not even possible yet to specify a thread index for
a watchpoint, the command pareser only accepts a thread argument
for normal breakpoints.
>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.
Thanks for your comments, Eli.
>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
You can see this is a comment added by Mark Kettenis
at line 707 of i386-linux-nat.c file:
/* FIXME: kettenis/2001-01-29: It's not clear what we should do with
multi-threaded processes here. For now, pretend there is just
one thread. */
Mark, wouldn't it be just enough to loop over the the thread chain
and call ptrace for each pid?
In any case, this comment clearly shows that the coreect behavior of a watchpoint
should be that it is triggered in all threads.
Christopher, does this answer your concerns?
Institut Charles Sadron
F 67083 STRASBOURG CEDEX (France)
Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99