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

[Pierre Muller <muller at cerbere dot u-strasbg dot fr>]

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
>least.

  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?





Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99