This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA]: Modified Watchthreads Patch
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.
> >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.
--
Daniel Jacobowitz