From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7525 invoked by alias); 11 Jul 2006 15:09:17 -0000 Received: (qmail 7514 invoked by uid 22791); 11 Jul 2006 15:09:16 -0000 X-Spam-Check-By: sourceware.org Received: from e31.co.us.ibm.com (HELO e31.co.us.ibm.com) (32.97.110.149) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 11 Jul 2006 15:09:12 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6BF9BKU021124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 11 Jul 2006 11:09:11 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6BF9BS3298008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Jul 2006 09:09:11 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k6BF9Ag9008531 for ; Tue, 11 Jul 2006 09:09:10 -0600 Received: from imap.linux.ibm.com (imap.raleigh.ibm.com [9.37.253.145]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6BF9A1j008511; Tue, 11 Jul 2006 09:09:10 -0600 Received: by imap.linux.ibm.com (Postfix, from userid 48) id 43BF545C046; Tue, 11 Jul 2006 11:09:10 -0400 (EDT) Received: from 9.125.1.154 ([9.125.1.154]) by imap.linux.ibm.com (Horde MIME library) with HTTP; Tue, 11 Jul 2006 11:09:10 -0400 Message-ID: <20060711110910.6298fq7oys0gwogw@imap.linux.ibm.com> Date: Tue, 11 Jul 2006 15:09:00 -0000 From: Wu Zhou To: eliz@gnu.org Cc: 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) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) 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/msg00089.txt.bz2 > This doesn't happen on x86, with this test program: > > #include > > int main (void) > { > int var1 =3D 0, var2; > var1 =3D 10; > var2 =3D var1; > > printf ("%d %d\n", var1, var2); > return 0; > } > > I think the reason it works for me is that on x86, there's no real > support for read watchpoints, so we actually set a read-write > watchpoint, and then the logic of watchpoint_check does TRT. > > What is the situation with this on a PPC? What kinds of data > breakpoints does it support, and what associated functionality can we > use in the ptrace call or its PPC equivalent? Embedded powerpc processors have optional hardware support (specilized=20=20 registers) for watchpoints. If these registers are available, they=20=20 will support read and write watchpoints at the same time. The=20=20 situation is the same with POWER processors. To insert read or write watchpoint, three new ptrace commands are=20=20 added for ppc/ppc64 kernel: SET_DEBUGREG, GET_DEBUGREG, GET_SIGINFO.=20=20 SET_DEBUGREG is used for setting the value of watchpoint register.=20=20 GET_DEBUGREG is for getting the value of watchpoint register.=20=20 GET_SIGINFO is for getting the siginfo struct when a trap is captured,=20=20 the watched data address is in this struct. >> My solution is to let gdb update the value stored in the watched > variable, >> so that it always get the fresh value for comparison. > That will work, but the question is: is this the optimal solution for > the PPC? Maybe there's a better solution, one that doesn't slow down > the normal case. Yes. This might slow down read watchpoint, mainly when there are more=20=20 write operation than read operation. But for write watchpoint, we can=20=20 eliminate that slowdown by only setting write flag. >> Another solution might be to change the verify logic of read watchpoint >> hit in watchpoint_check. Maybe we can just trust the underlying os will >> only trigger in read hit? > > The question is, how to do that without breaking other platforms, like > x86, which we cannot trust. If you can come up with a design that > accommodates both types of situations, I will be happy to review it. I am not that familar with the situation in x86 platform. But I am=20=20 willing to take some look into that to see if I can come out with any=20=20 solution. > Daniel, could you please point me to Ulrich's change, either in > ChangeLogs or in the sources? I cannot find it forf some reason. > >> Comparing all these solution, my solution is the most simple one. I > mean, >> it makes little change to the current code. To address the slowdown, we >> can still use the original flags for write hit. >> >> What is your idea on this? > > 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=20=20 purpose. Every target can set that up when it initializes. What is=20=20 more, the underlying os need to tell what kind of watchpoint it=20=20 reports, maybe in the transfered-back siginfo struct. Then gdb can use=20=20 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=20=20 method. The underlying os need to tell what the watchpoint hit is,=20=20 read or write. Current ppc/ppc64 kernel don't do that. it just report=20=20 the a hw watchpoint is hit and report the data address to gdb through=20=20 siginfo struct. So what about commit my code first, although there are some slowdown.=20=20 And then we can follow the above method to resolve the problem in both=20=20 kernel and gdb side? > Please note that there are complications in this area: a user could > have legitimately set several different watchpoints on the same > address, each one with its own type (read, write, access) and its own > set of conditions and/or commands. Whatever new design we come up > with, it has to support these complicated situations, because the user > will expect GDB to announce only those watchpoints which meet the > conditions and type constraints. For example, what happens with your > solution if I put both read and write watchpoints on the same > variable? The current code does TRT on x86 in that case. As you see > below, it correctly announces each one of the two watchpoints where > expected (except for a slight off-by-one shift in line numbers): My current code can handle this situation. Regards - Wu Zhou