This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 0/1] Threaded Watchpoints
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: uweigand at de dot ibm dot com
- Cc: drow at false dot org, gdb-patches at sourceware dot org
- Date: Mon, 10 Sep 2007 21:31:25 +0200 (CEST)
- Subject: Re: [patch 0/1] Threaded Watchpoints
- References: <200709101903.l8AJ3Q7W012168@d12av02.megacenter.de.ibm.com>
> Date: Mon, 10 Sep 2007 21:03:26 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
>
> 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 ...
That really is the wrong way to think about this; we shouldn't keep
gdb criplled forever, just because some bad decision was made years
and years ago.
So the real question here is, whether HAVE_NONSTEPPABLE_WATCHPOINT and
these other properties mentions above are really a fundamental
property of the architecture (ISA or OS ABI). Or if they are
properties of a particular debug interface (ptrace, remote, jtag).
In some cases it may actually make sense to have something as a
property of the architecture but making it possible for the target
vector to override it.
Mark