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]

Re: Getting the i386 watchpoints into the taget vector?


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''?
(Probably bad choice of words).

GDB can implement watchpoints, for a remote target, using two mechanism:

- sending the remote target the watchpoint request (the Z packet) and let the remote target implement the details

- manipulate the h/w watchpoint registers directly, sending the remote target register read/write operations - what I believe i386-nat.c does.

The native equivalents are roughly:

- use some sort of custom h/w watchpoint kernel interface

- use ptrace(PT_GETREGS) / ptrace (PT_SETREGS)


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.
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.

Andrew

PS: Someone should implement the equivalent sim commands. sim/common has a watchpoint framework. Just needs the sim<->gdb interface.



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