Re: [RFA]: Modified Watchthreads Patch

[Daniel Jacobowitz <drow@false.org>]

On Fri, Dec 10, 2004 at 06:52:37PM -0500, Jeff Johnston wrote:
> 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.

As Eli says, there are some design issues with the rest of the x86
watchpoint code that make me nervous about doing this.

> 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.
> 
> As I observed before, the actual watchpoint only needs to be set on one 
> thread and it will trigger in other threads.  I can send you the additional 
> patch if you want to experiment with it.  I am still waiting for a machine 
> with the latest RH kernel on it.  I'll let you know if that works the same.

I'm glad to hear that it works for you.  However, since the kernel
sources that I have here patently say that it shouldn't, we need to
understand why.  Do the RHEL kernels have local changes to watchpoint
support?  arch/i386/kernel/ptrace.c and arch/i386/kernel/process.c
should have all the relevant bits.

-- 
Daniel Jacobowitz