From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27604 invoked by alias); 20 Sep 2002 23:51:56 -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 27597 invoked from network); 20 Sep 2002 23:51:55 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 20 Sep 2002 23:51:55 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 5BE2F3D34; Fri, 20 Sep 2002 19:51:53 -0400 (EDT) Message-ID: <3D8BB499.7080306@ges.redhat.com> Date: Fri, 20 Sep 2002 16:51:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: Getting the i386 watchpoints into the taget vector? References: <3D8A8094.5080908@ges.redhat.com> <5137-Sat21Sep2002004300+0300-eliz@is.elta.co.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00331.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''? (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.