Re: [patch 0/1] Threaded Watchpoints

["Ulrich Weigand" <uweigand@de.ibm.com>]

Daniel Jacobowitz wrote:
> On Mon, Sep 10, 2007 at 08:44:22PM +0200, Ulrich Weigand wrote:
> > 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 ...)
> 
> I totally agree.  I just don't know which one makes more sense.
> Probably gdbarch but I'm sure I'll break something if I try to
> change it.

I'd tend to agree with Andrew's comment in mips-tdep.c:

  /* FIXME: cagney/2003-08-29: The macros HAVE_STEPPABLE_WATCHPOINT,
     HAVE_NONSTEPPABLE_WATCHPOINT, and HAVE_CONTINUABLE_WATCHPOINT
     need to all be folded into the target vector.  Since they are
     being used as guards for STOPPED_BY_WATCHPOINT, why not have
     STOPPED_BY_WATCHPOINT return the type of watchpoint that the code
     is sitting on?  */

Since all other watchpoint-related callbacks are in the target 
vector, having nonsteppable_watchpoint as a gdbarch property
does look somewhat odd.

The only problem with moving HAVE_NONSTEPPABLE_WATCHPOINT into the
target vector might be the remote targets.  Is this information
available via the remote protocol somehow?  If not, I guess it has
to stay in gdbarch ...

> > Hmm, I see.  This assumes that after every new-thread event, the new
> > thread is selected as inferior_ptid, though.
> 
> I don't think it assumes that.  s390_resume should be called once for
> each thread, and not depend on inferior_ptid at all; only
> linux_nat_resume has to check for ptid == -1, schedlocking, et cetera.

Doh!  You're right, of course.  That should work fine then.

Bye,
Ulrich

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