Re: [patch 0/1] Threaded Watchpoints

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Daniel Jacobowitz wrote:
> On Mon, Sep 10, 2007 at 08:22:56PM +0200, Ulrich Weigand wrote:
> > Was the change to remove use of HAVE_CONTINUABLE_WATCHPOINTS deliberate?
> > It used to be that you had to set one of the three flags in order to
> > activate the watchpoint logic at all, but your new code will always
> > call STOPPED_BY_WATCHPOINT.
> 
> Yes - do you think I shouldn't?  Easy enough to put it back.

I guess your new way makes more sense.  This means we can remove
HAVE_CONTINUABLE_WATCHPOINTS completely, though.  (As a related
point, I think it would be good to fix the oddity that nonsteppable
watchpoints are reported as a gdbarch property while steppable
watchpoints are reported as a target property ...)

> > This assumes that the new thread's ptid will always be passed to the
> > resume.  Is this necessarily the case?  I would expect ptid to be -1
> > in most cases ...
> 
> It is necessarily the case.  This function is never called through
> target_resume, only through linux_nat_resume.  This was one of the big
> cleanups that made my patch possible.

Hmm, I see.  This assumes that after every new-thread event, the new
thread is selected as inferior_ptid, though.  This unfortunately 
interferes with a patch I'm working on right now: when a new thread
event (or shared library event) occurs while we're currently single-
stepping another thread, things don't work very well right now.
I was proposing to fix this by always selecting the thread being
stepped as current thread again after processing the event ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com