This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
gdb/735: Getting the i386 watchpoints into the target vector?
- From: ac131313 at redhat dot com
- To: gdb-gnats at sources dot redhat dot com
- Date: 27 Sep 2002 17:39:55 -0000
- Subject: gdb/735: Getting the i386 watchpoints into the target vector?
- Reply-to: ac131313 at redhat dot com
>Number: 735
>Category: gdb
>Synopsis: Getting the i386 watchpoints into the target vector?
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Fri Sep 27 10:48:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: ac131313@redhat.com
>Release: unknown-1.0
>Organization:
>Environment:
>Description:
See thread:
http://sources.redhat.com/ml/gdb/2002-09/msg00300.html
Hello,
With the watchpoint interface made part of the target vector, its time to think about how the i386 case should be handled. Instead of using a system interface, the i386 manipulates the hardware watchpoint registers directly. For want of a better name, I'll call this ``native watchpoints''.
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.
Thoughts? Better ideas?
Andrew
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: