From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23535 invoked by alias); 9 Dec 2005 02:25:50 -0000 Received: (qmail 23525 invoked by uid 22791); 9 Dec 2005 02:25:49 -0000 X-Spam-Check-By: sourceware.org Received: from ausmtp04.au.ibm.com (HELO ausmtp04.au.ibm.com) (202.81.18.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 09 Dec 2005 02:25:47 +0000 Received: from sd0112e0.au.ibm.com (d23rh903.au.ibm.com [202.81.18.201]) by ausmtp04.au.ibm.com (8.12.10/8.12.10) with ESMTP id jB92T12N058868 for ; Fri, 9 Dec 2005 13:29:05 +1100 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.250.237]) by sd0112e0.au.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jB92SbFk200682 for ; Fri, 9 Dec 2005 13:28:38 +1100 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.12.11/8.13.3) with ESMTP id jB92PWhO025602 for ; Fri, 9 Dec 2005 13:25:32 +1100 Received: from [9.181.133.252] ([9.181.133.252]) by d23av04.au.ibm.com (8.12.11/8.12.11) with ESMTP id jB92PTvT025505; Fri, 9 Dec 2005 13:25:30 +1100 Date: Fri, 09 Dec 2005 12:04:00 -0000 From: Wu Zhou To: Daniel Jacobowitz cc: gdb-patches@sources.redhat.com, mark.kettenis@xs4all.nl Subject: Re: [RFC] GDB patches for hw watchpoints - revised In-Reply-To: <20051206202848.GA9568@nevyn.them.org> Message-ID: References: <20051206202848.GA9568@nevyn.them.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: 2005-12/txt/msg00162.txt.bz2 On Tue, 6 Dec 2005, Daniel Jacobowitz wrote: > On Tue, Dec 06, 2005 at 10:25:01PM +0200, Eli Zaretskii wrote: > > > Date: Tue, 6 Dec 2005 14:12:26 +0800 (CST) > > > From: Wu Zhou > > > cc: drow@false.org, eliz@gnu.org, mark.kettenis@xs4all.nl > > > > > > 3. Eli ever expressed a concern that the PPC doesn't have a way to return > > > the data address that triggered the watchpoint? As far as I think, the > > > reason is that PPC will only have one DABR (if it does have). So maybe we > > > don't need to have such a method. > > > > Sorry, I'm not following: no matter how many debug registers the PPC > > has, it can still return to GDB the data address that triggered the > > watchpoint. I don't think the higher levels of GDB (breakpoint.c) > > should know or assume anything about the target capabilities or > > resources. Let's try keeping the code clean of such peculiarities. > > Wu, you're using GETSIGINFO to check for a watchpoint. Then isn't the > faulting address stored in the siginfo anyway? Currently what stored in the siginfo.si_addr is the address of next instruction. Anton sent me a patch to change that to the data address instead. I am now playing with the patched kernel. BTW. It seems that to_stopped_data_address is only used in rwatch and awatch, which is not that frequently used as watch itself. So may we postpone its implementation till some later time? Regards - Wu Zhou