From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21461 invoked by alias); 12 Jul 2006 17:31:31 -0000 Received: (qmail 21453 invoked by uid 22791); 12 Jul 2006 17:31:31 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 12 Jul 2006 17:31:28 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G0iYX-0006bz-DA; Wed, 12 Jul 2006 13:31:25 -0400 Date: Wed, 12 Jul 2006 17:31:00 -0000 From: Daniel Jacobowitz To: Wu Zhou Cc: eliz@gnu.org, gdb-patches@sourceware.org Subject: Re: Fw: [ppc-linux-nat]: set access flag for h/w watchpoint even if it is only read or write (fwd) Message-ID: <20060712173125.GC24622@nevyn.them.org> Mail-Followup-To: Wu Zhou , eliz@gnu.org, gdb-patches@sourceware.org References: <20060711110910.6298fq7oys0gwogw@imap.linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060711110910.6298fq7oys0gwogw@imap.linux.ibm.com> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00113.txt.bz2 On Tue, Jul 11, 2006 at 11:09:10AM -0400, Wu Zhou wrote: > >I think the cleanest solution is for breakpoint.c to get the idea of > >the kind of support it can get from the target. If the target > >implements real read watchpoints, it should propagate that knowledge > >to breakpoint.c, where it examines the watchpoints and decides which > >one to announce. > > Yes. That is a good idea. Maybe a target vector can be added for that > purpose. Every target can set that up when it initializes. What is > more, the underlying os need to tell what kind of watchpoint it > reports, maybe in the transfered-back siginfo struct. Then gdb can use > that information to know if it is a read hit or write hit. > > Although it is the very clean, but there is one problem in this > method. The underlying os need to tell what the watchpoint hit is, > read or write. Current ppc/ppc64 kernel don't do that. it just report > the a hw watchpoint is hit and report the data address to gdb through > siginfo struct. There's two issues here, I think. They solve different problems. First, there's the question of targets which can't set true "read" watchpoints, but can set "access" watchpoints. Right now the x86 simply accepts a request to insert a read watchpoint, and generates an access watchpoint instead. How about if we changed it to refuse to insert read watchpoints, changed breakpoint.c to attempt an access watchpoint if inserting a read watchpoint fails, and then store in the breakpoint which type was inserted? In b->loc is probably a good place. Right now there's no information there about which kind of watchpoint was inserted. We could add a new field, and store hw_read/hw_access/hw_write in it when we insert the breakpoint. Would that fix this problem? Second, there's the question of which sort of watchpoint we've hit. If the target could tell us, say, as a return value from target_stopped_data_address, then we could only check read watchpoints when a read watchpoint triggers. But I think this is a smaller issue; at worst we might report that both a write and read watchpoint had triggered when really only a write watchpoint had. And there's corner cases, like instructions which both read and write an address; they should trigger both read and write watchpoints but I doubt any platform gives us enough information to figure out that that's happened. -- Daniel Jacobowitz CodeSourcery