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: Remote watchpoint support for FRV


Daniel Jacobowitz wrote:
> On Fri, Oct 05, 2007 at 03:47:53PM +0200, Ulrich Weigand wrote:
> > Hello,
> > 
> > the tm-frv.h header file overrides a number of watchpoint related
> > target macros, in particular:
> > 
> > #define STOPPED_BY_WATCHPOINT(W) \
> >    ((W).kind == TARGET_WAITKIND_STOPPED \
> >    && (W).value.sig == TARGET_SIGNAL_TRAP \
> >    && frv_have_stopped_data_address())
> 
> Kevin, you were the last person to work on the FRV target (far as I
> can tell); do you know anything about this?

Any updates on this?  I've had another look at this, and it appears
to me that this wasn't actually functional in mainline GDB anyway:
Up until your recent breakpoint.c change, watchpoints were active 
only if either HAVE_STEPPABLE_WATCHPOINT, HAVE_NONSTEPPABLE_WATCHPOINT,
or HAVE_CONTINUABLE_WATIPOINT were defined.

In this particular case, the tm file doesn't define any of these (the
#define HAVE_STEPPABLE_WATCHPOINT is commented out), an nm file doesn't
apply, the remote target does not define to_have_continuable_watchpoint,
and frv-tdep does not use set_gdbarch_nonsteppable_watchpoint.

Thus it would appear that the STOPPED_BY_WATCHPOINT and 
target_stopped_data_address macros defined in the tm-frv.h header
file aren't actually ever called.  (Since the recent watchpoint change,
they *are* active, but probably not correctly as common code now assumes
continuable watchpoint behaviour).

Note that the HAVE_STEPPABLE_WATCHPOINT macro is commented out since the
very first version of tm-frv.h checked into the GDB CVS, so I'm not sure
what to think of that ...  Did this ever work?

If it actually didn't ever work, I'd say we should just remove the tm
file now; if somebody wants to get remote watchpoint support on frv
working, they can (and should) use the existing mechanism.

> Ulrich, there's a third option, but I don't know if it's practical.
> Can we somehow specialize the remote target based on the architecture?
> It's not the first time I've thought it would be useful.  But we
> already have the target adjusting the architecture and adding
> something in the other direction might be awkward.

I agree this would probably be a bit awkward ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


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