Re: [RFA 2/3] Demote to sw watchpoint only in update_watchpoint

[Pedro Alves <pedro@codesourcery.com>]

On Tuesday 03 May 2011 17:55:53, Eli Zaretskii wrote:
> > From: Pedro Alves <pedro@codesourcery.com>
> > Date: Tue, 3 May 2011 10:58:44 +0100
> > Cc: Thiago Jung Bauermann <bauerman@br.ibm.com>,
> >  uweigand@de.ibm.com
> > 
> > What if we tried to make GDB do that instead? (try inserting
> > watchpoint immediately, instead of trying to do any sort of
> > accounting.)
> 
> That could work, but won't it get us in trouble, e.g., when there are
> other threads running?  They could inadvertently hit those watchpoints
> while we are trying to insert them, no?

That would be no trouble, I think.  If we're midway trying to insert
them, it should be okay to hit them.  The problem case I can think of
is if we're installing e.g., 3 (low-level) watchpoints locations for a
single watchpoint, say, and we fail on the third.  When that
happens, we need to delete the first two watchpoints locations.  A thread
may meanwhile hit one of those watchpoints, and gdb would only see the
event _after_ the watchpoint location being long deleted.  But, GDB already
has to handle this situation situation anyway, because it's
what happens when you simply delete a watchpoint in non-stop
mode -- GDB will simply ignore such watchpoint events it can't explain.

> 
> Or we could let targets which needs that (e.g., those using jtag as
> you described) try inserting the watchpoints to respond to GDB's
> request in target_can_use_hardware_watchpoint.  Other targets, which
> can decide that without inserting, would not need to do that.
> 
> WDYT?

The main point/win of the suggestion was avoiding the whole
resource accounting infrastructure, getting away without adding
a bunch of (what looks to me at this point, unnecessary) target
methods/packets/logic.

-- 
Pedro Alves