Re: [RFA]: Modified Watchthreads Patch

[Jeff Johnston <jjohnstn@redhat.com>]

Jeff Johnston wrote:
> Daniel Jacobowitz wrote:
> 
>> On Fri, Dec 10, 2004 at 03:02:41PM -0500, Jeff Johnston wrote:
>>
>>>> On the technical side, two questions:
>>>>
>>>> 1) I can see that it will be a bit of work to rearrange i386-linux to
>>>> use this, but it should be doable.  Do you know offhand of any
>>>> i386-specific problems other than inserting watchpoints for all
>>>> threads?
>>>>
>>>
>>> Actually, with i386/x86-64 I discovered that the debug registers are 
>>> global in scope for the setting of watchpoints (i.e. I didn't have to 
>>> use the observer). The status register, however, is thread-specific 
>>> for reporting them.  I have gotten the watchthreads.exp testcase 
>>> working for both platforms.  Your lwp fix helps a lot with this.  We 
>>> call TIDGET()/PIDGET() in the low-level code which used to get called 
>>> in the wrong ptid mode so we kept checking the main-thread for the 
>>> watchpoint.
>>
>>
>>
>> Er... do you know why the debug registers are global, and what kernel
>> is this with?  They look thread-specific to me (kernel 2.6.10-rc1). 
>> They are accessible using PEEKUSR/POKEUSR for each thread, and
>> __switch_to updates them at context switches.
>>
> 
> I am simply speaking from experience with the RHEL3 kernel.  I got it 
> working without touching the insert/remove logic.  I am currently 
> retrofitting new changes into the mainline gdb that are much "cleaner" 
> than my previous fixes.  I haven't tried x86 on the latest kernel, but I 
> am in the midst of putting together an uber-patch with the stuff here 
> plus some other things needed for each platform.  IA64 is already 
> finished and running watchthreads.exp on a next-release kernel.  I am 
> about to start x86 so I will keep in mind your comment.  I'll let you 
> know either way what I had to do to get it working.
>

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.

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.

-- Jeff J.