This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 2/3] Demote to sw watchpoint only in update_watchpoint
- From: Pedro Alves <pedro at codesourcery dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb-patches at sourceware dot org, bauerman at br dot ibm dot com, uweigand at de dot ibm dot com
- Date: Tue, 3 May 2011 18:41:46 +0100
- Subject: Re: [RFA 2/3] Demote to sw watchpoint only in update_watchpoint
- References: <201104291726.p3THQVaC029608@d06av02.portsmouth.uk.ibm.com> <201105031058.44489.pedro@codesourcery.com> <83iptr4tba.fsf@gnu.org>
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