From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23632 invoked by alias); 13 Dec 2005 20:35:51 -0000 Received: (qmail 23625 invoked by uid 22791); 13 Dec 2005 20:35:50 -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; Tue, 13 Dec 2005 20:35:49 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EmGsE-00033V-9g; Tue, 13 Dec 2005 15:35:46 -0500 Date: Wed, 14 Dec 2005 18:13:00 -0000 From: Daniel Jacobowitz To: Wu Zhou Cc: gdb-patches@sources.redhat.com, mark.kettenis@xs4all.nl, bje@au1.ibm.com, anton@au1.ibm.com Subject: Re: [RFC] GDB patches for hw watchpoints - revised Message-ID: <20051213203546.GA11674@nevyn.them.org> Mail-Followup-To: Wu Zhou , gdb-patches@sources.redhat.com, mark.kettenis@xs4all.nl, bje@au1.ibm.com, anton@au1.ibm.com References: <20051206202848.GA9568@nevyn.them.org> <20051209050132.GA5325@nevyn.them.org> <20051210044752.GA30979@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i 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/msg00218.txt.bz2 On Tue, Dec 13, 2005 at 02:10:03PM +0800, Wu Zhou wrote: > 2. The second one need Anton's patch, which changed three lines in > arch/ppc64/mm/fault.c: > With this patch, I can use PTRACE_GETSIGINFO to get the stopped data > address (it is in siginfo.si_addr). But one problem is that > to_stopped_by_watchpoint will call PTRACE_GETSIGINFO first to determine if > the stop is caused by watchpoint. And another problem is that gdb need to > single step the process to execute current instruction when a watchpoint > is hit. This will again drop into bpstat_stop_status, which will call > stopped_by_watchpoint and thus call PTRACE_GETSIGINFO again. > > I take a look at IA64's code, it set the dd bit of IA64_PSR_REGNUM, which > will disable the watchpoint for the next instruction. But it seems that > ppc don't have such a way. Do we have any workaround for this? Could you cache the stopped data address when we are stopped by a watchpoint, and then return the cached one if we aren't stopped by a watchpoint any more but were the previous instruction? I realize this is gross; the entire "step, then check the stopped data address" is a bad idea, in my opinion. > 3. The third one is a little tricky. Now that ppc has at most 1 DABR. So > I can set the stopped_data_address to the data address when we set the > watchpoint (in ppc_linux_insert_watchpoint). Everytime > target_stopped_data_address is called, the breakpoint is either read or > access, so it is already clear that it is stopped by watchpoint. Then > this trick seems to make sense, right? Weren't there other PPCs with more than one though? > I had tested the above three methods. The first one works ok when the > data breakpoint is aligned by 8 bytes. The third one works ok for both > aligned and non-aligned data breakpoint. For the second one, I don't know > how to work around the extra PTRACE_GETSIGINFO call caused by the single > step yet. But if I reserver the stopped_data_address when we first > hit watchpoint, and store it back when I call ppc_linux_stopped_data_address. > I can make rwatch and awatch to work as expected. ... right, I guess I should have read your whole message first! That's my preferred option if we can find a clean way to do it. I thought there was a target with an example of this, but I can't find it. I'm not sure I understand why ia64 needs to disable the watchpoint, though. -- Daniel Jacobowitz CodeSourcery, LLC