From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19690 invoked by alias); 7 Jul 2006 04:35:28 -0000 Received: (qmail 19679 invoked by uid 22791); 7 Jul 2006 04:35:27 -0000 X-Spam-Check-By: sourceware.org Received: from e33.co.us.ibm.com (HELO e33.co.us.ibm.com) (32.97.110.151) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Jul 2006 04:35:24 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k674ZNdo010041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 7 Jul 2006 00:35:23 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k674Zj9C161876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Jul 2006 22:35:46 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k674ZMLM023499 for ; Thu, 6 Jul 2006 22:35:22 -0600 Received: from imap.linux.ibm.com (imap.raleigh.ibm.com [9.37.253.145]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k674ZLbR023496; Thu, 6 Jul 2006 22:35:22 -0600 Received: by imap.linux.ibm.com (Postfix, from userid 48) id BB56145C032; Fri, 7 Jul 2006 00:35:21 -0400 (EDT) Received: from 9.181.133.162 ([9.181.133.162]) by imap.linux.ibm.com (Horde MIME library) with HTTP; Fri, 7 Jul 2006 00:35:21 -0400 Message-ID: <20060707003521.worrm140yso4g8s8@imap.linux.ibm.com> Date: Fri, 07 Jul 2006 04:35:00 -0000 From: Wu Zhou To: Eli Zaretskii , Daniel Jacobowitz Cc: gdb-patches@sourceware.org Subject: Re: [ppc-linux-nat]: set access flag for h/w watchpoint even if it is only read or write 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/msg00048.txt.bz2 Eli, Just as Daniel said, my problem is not the same as yours. given the following code: int var1 =3D 0, var2; var1 =3D 10; var2 =3D var1; if we set read watchpoint on var1, it should stop at "var2 =3D var1", but gdb are using "watchpoint_check" to see if the watched variable are changed or not, if it is changed, then it assumes the watched variable is writed; if not, it assumes the watched variable is read. Because when execution get to "var1=3D10", it won't trigger a watchpoint, the old value stored in var1 is still 0, so watchpoint_check will get a wrong conclusion that var1 is changed to 10 by this instruction. So it won't treat it as a read watchpoint hit. My solution is to let gdb update the value stored in the watched variable, so that it always get the fresh value for comparison. 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? Still another is like what Daniel and you said, we can let the target to tell what kind of hit it is on the watched variable. As for this, I can figure out two methods at this time: the kernel should transfer the watchpoint type information to user space (maybe through siginfo), or gdb iterate through all the watched variable to determine what kind of watchpoint this is. Both of these changes also involve the change in watchpoint_check routine. 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? On Thu, 6 Jul 2006, Daniel Jacobowitz wrote: > On Thu, Jul 06, 2006 at 11:58:58PM +0300, Eli Zaretskii wrote: > > Yes, this problem is known on x86 and elsewhere. The problem is > > extremely rare, as reading and writing to the same address in the same > > instruction is a hard-to-accomplish treat. Wu, could you show a > > real-life example of where this matters? > > I thought, though I may be misremembering, that it was actually a > different problem. Something like this: > > - We set a read watchpoint. It does not trigger on writes. > > - An instruction writes to the location. > > - GDB stops, sees that it stopped at a watchpoint at the given address, > tries to determine what sort of watchpoint it was, determines that > the value had changed, and ignores the read watchpoint - the value > has changed since we last checked so this "must" have been a write > watchpoint. > > Is that plausible or nonsensical? > > -- > Daniel Jacobowitz > CodeSourcery > Regards - Wu Zhou