From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7441 invoked by alias); 20 Sep 2002 21:42:34 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7426 invoked from network); 20 Sep 2002 21:42:33 -0000 Received: from unknown (HELO odin.inter.net.il) (192.114.186.10) by sources.redhat.com with SMTP; 20 Sep 2002 21:42:33 -0000 Received: from Zaretsky ([80.230.2.40]) by odin.inter.net.il (Mirapoint Messaging Server MOS 3.1.0.58-GA) with ESMTP id ANY65597; Sat, 21 Sep 2002 00:42:19 +0300 (IDT) Date: Fri, 20 Sep 2002 14:42:00 -0000 From: "Eli Zaretskii" To: ac131313@ges.redhat.com Message-Id: <5137-Sat21Sep2002004300+0300-eliz@is.elta.co.il> CC: gdb@sources.redhat.com In-reply-to: <3D8A8094.5080908@ges.redhat.com> (message from Andrew Cagney on Thu, 19 Sep 2002 21:57:40 -0400) Subject: Re: Getting the i386 watchpoints into the taget vector? Reply-to: Eli Zaretskii References: <3D8A8094.5080908@ges.redhat.com> X-SW-Source: 2002-09/txt/msg00320.txt.bz2 > Date: Thu, 19 Sep 2002 21:57:40 -0400 > From: Andrew Cagney > > 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?