This is the mail archive of the gdb@sources.redhat.com 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] |
(Probably bad choice of words).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''?
I'm not sure what you mean here. If we used macro's then they would run afowl of trying to make everything multi-arch.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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |