Re: [RFA]: Modified Watchthreads Patch

["Eli Zaretskii" <eliz at gnu dot org>]

> Date: Fri, 10 Dec 2004 18:52:37 -0500
> From: Jeff Johnston <jjohnstn@redhat.com>
> Cc: Daniel Jacobowitz <drow@false.org>, gdb-patches@sources.redhat.com
> 
> Interesting results.  Applying my previous patch and just changing the FIXME 
> code in dr_get_register and dr_set_register to use the standard:
> 
> tid = TIDGET (inferior_ptid);
> if (tid == 0)
>    tid = PIDGET (inferior_ptid);
> 
> allows watchthreads.exp to work for both x86 and x86_64.  For x86, I used an fc3 
> system with a 2.6.9-1.667smp kernel.  I had to use an RHEL3 2.4 kernel for x86-64.
> 
> The test sets two watchpoints that will be triggered once in the main thread and 
> thereafter in two distinct threads.  The test verifies that each value is 
> incremented as it should in the correct thread.  It makes sure there are no 
> missing jumps.  I have witnessed multiple watchpoint events and thread creation 
> events requiring processing at the same time (i.e. deferred events required) and 
> it handles these correctly.
> 
> I tried an experiment and broke in the thread function in one of the threads.  I 
> then watched a variable that can only be triggered in a separate thread.  That 
> also worked which was cool.

While I'm happy it worked for you, please be sure to test somewhat
more complex uses of watchpoints, viz.:

 . Setting several watchpoints on the same data (perhaps with
   different conditions), in the same thread and in several different
   threads.

 . use rwatch and awatch, not only watch, commands to put
   watchpoints.  As you might know, GDB handles data-write watchpoints
   with a different branch of code than what it uses for data-read and
   data-access watchpoints; we need to test both branches to be really
   sure the code works for threaded programs.

For single-threaded programs, the watchpoint support in i386-nat.c
works correctly in the above two classes of complex usage.  In
particular, it allows you to set an unlimited amount of watchpoints of
the same type on the same data, even though there are only 4 debug
registers we can use on x86.  We need to be sure that code doesn't
break for multi-threaded programs.

> As I observed before, the actual watchpoint only needs to be set on
> one thread and it will trigger in other threads.

One issue we should discuss is do we really want this behavior?  Do we
really want GDB to stop the inferior when another thread hits the
watchpoint that we set in a specific thread, or do we want a
watchpoint to break only in the thread in which it was set?  There are
valid arguments for both alternatives, and we never came to any
resolution of this issue, since back when it was discussed, the state
of support in GDB for multi-threaded programs was in flux.