This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Getting the i386 watchpoints into the taget vector?
- From: "Eli Zaretskii" <eliz at is dot elta dot co dot il>
- To: ac131313 at ges dot redhat dot com
- Cc: gdb at sources dot redhat dot com
- Date: Sat, 21 Sep 2002 00:43:00 +0300
- Subject: Re: Getting the i386 watchpoints into the taget vector?
- References: <3D8A8094.5080908@ges.redhat.com>
- Reply-to: Eli Zaretskii <eliz at is dot elta dot co dot il>
> Date: Thu, 19 Sep 2002 21:57:40 -0400
> From: Andrew Cagney <ac131313@ges.redhat.com>
>
> Instead of using a system interface, the i386 manipulates the
> hardware watchpoint registers directly.
Really? What I see is that most i386 ports use ptrace or similar
interfaces to access the hardware watchpoints. So in what sense is
this manipulation ``direct''?
> One thought is to change the config/i386/nm-i386.h macros to something
> native specific (native_insert_watchpoint()) and then have the various
> native targets (infptrace.c, ...) add these methods to their target vector.
>
> It does restrict things to native targets. A remote target couldn't
> make use of GDB's built-in knowledge of watchpoint registers.
>
> Another (less well thought out) idea, is for the target stack, to fall
> back to the ``native watchpoint'' mechanism when the [remote] target
> doesn't support watchpoints. I think this would mean putting the
> ``native watchpoint'' methods in the architecture vector where the
> target vector code could call it.
Why not simply allow remote targets define the watchpoint-related
macros? Let their definitions issue remote packets that will cause
the target end DTRT. As long as the target is a i386-compatible
machine, the internal bookkeeping we have in the current code will
work.
Am I missing something?