Re: [RFA]: Modified Watchthreads Patch

Jeff Johnston
2004-12-10T21:35:22Z

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.

>
>>>2) What should to_stopped_by_watchpoint do in the presence of multiple
>>>threads? It looks like it relies on inferior_ptid being the thread
>>>which stopped at a watchpoint; I'm worried that that may not be
>>>consistently true in a heavily threaded application. Maybe it should
>>>iterate over all threads.
>>>
>>
>>It works fine for the watchthreads.exp test once all the mechanisms are in
>>place (I have a few more patches to go). We don't want to iterate over all
>>threads unless we know the platform has a problem. Otherwise, we won't be
>>able to pin down a specific watchpoint triggered with the thread/source
>>line that triggered it. Is there a valid scenario where inferior_ptid
>>should not be the thread for the signal chosen by the low-level linux-nat
>>code? If not, I would prefer to treat that as a bug that requires pinning
>>down.
>
>
> We can delay this issue, then. I am concerned about losing watchpoints
> when other events are active, e.g. a thread event breakpoint or dlopen
> breakpoint and a read watchpoint. I'm sure GDB gets this wrong
> already.
>
> Please fix the whitespace at the end of s390-nat.c. Otherwise, this is
> approved if Ulrich is OK with the S390 bits; let's give him a chance to
> comment.
>

Great. Will make the white-space change and wait for Ulrich.

-- Jeff J.