[RFA 2/3] Demote to sw watchpoint only in update_watchpoint
Pedro Alves
pedro@codesourcery.com
Tue May 3 17:41:00 GMT 2011
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
More information about the Gdb-patches
mailing list