This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch 0/1] Threaded Watchpoints


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]