From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10090 invoked by alias); 7 Jul 2006 10:04:49 -0000 Received: (qmail 10001 invoked by uid 22791); 7 Jul 2006 10:04:48 -0000 X-Spam-Check-By: sourceware.org Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (192.114.186.20) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Jul 2006 10:04:40 +0000 Received: from HOME-C4E4A596F7 (IGLD-84-228-163-164.inter.net.il [84.228.163.164]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id EAU71426 (AUTH halo1); Fri, 7 Jul 2006 13:04:36 +0300 (IDT) Date: Fri, 07 Jul 2006 10:04:00 -0000 Message-Id: From: Eli Zaretskii To: Wu Zhou CC: gdb-patches@sourceware.org In-reply-to: <20060707003521.worrm140yso4g8s8@imap.linux.ibm.com> (message from Wu Zhou on Fri, 7 Jul 2006 00:35:21 -0400) Subject: Re: [ppc-linux-nat]: set access flag for h/w watchpoint even if it is only read or write Reply-to: Eli Zaretskii References: <20060707003521.worrm140yso4g8s8@imap.linux.ibm.com> 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/msg00051.txt.bz2 > Date: Fri, 7 Jul 2006 00:35:21 -0400 > From: Wu Zhou > Cc: gdb-patches@sourceware.org > > Just as Daniel said, my problem is not the same as yours. given the > following code: > > int var1 = 0, var2; > var1 = 10; > var2 = var1; > > if we set read watchpoint on var1, it should stop at "var2 = 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=10", 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. This doesn't happen on x86, with this test program: #include int main (void) { int var1 = 0, var2; var1 = 10; var2 = 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? > 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. > 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. 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. 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): GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-mingw32"... (gdb) start Breakpoint 1 at 0x4012b5: file wpt.c, line 4. Starting program: D:\usr\eli\data/./wpt.exe main () at wpt.c:4 4 { (gdb) watch var1 Hardware watchpoint 2: var1 (gdb) rwatch var1 Hardware read watchpoint 3: var1 (gdb) c Continuing. Hardware watchpoint 2: var1 Old value = 2 New value = 0 main () at wpt.c:6 6 var1 = 10; (gdb) Continuing. Hardware watchpoint 2: var1 Old value = 0 New value = 10 main () at wpt.c:7 7 var2 = var1; (gdb) Continuing. Hardware read watchpoint 3: var1 Value = 10 0x004012cb in main () at wpt.c:7 7 var2 = var1; (gdb) Continuing. Hardware read watchpoint 3: var1 Value = 10 0x004012d8 in main () at wpt.c:9 9 printf ("%d %d\n", var1, var2); (gdb) Continuing. 10 10 Watchpoint 2 deleted because the program has left the block in which its expression is valid.