From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7137 invoked by alias); 13 Nov 2005 16:45:59 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 7099 invoked by uid 22791); 13 Nov 2005 16:45:53 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 13 Nov 2005 16:45:53 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EbKzE-0000Pm-G9; Sun, 13 Nov 2005 11:45:48 -0500 Date: Sun, 13 Nov 2005 16:45:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Vladimir Prus , gdb@sources.redhat.com Subject: Re: read watchpoints ignored? Message-ID: <20051113164546.GA465@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Vladimir Prus , gdb@sources.redhat.com References: <200511111622.01337.ghost@cs.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-11/txt/msg00242.txt.bz2 On Fri, Nov 11, 2005 at 08:19:41PM +0200, Eli Zaretskii wrote: > > (gdb) b main > > Breakpoint 1 at 0x80483a4: file rw.cpp, line 8. > > (gdb) r > > Starting program: /tmp/a.out > > > > Breakpoint 1, main () at rw.cpp:8 > > 8 a = 10; > > (gdb) rwatch a > > Hardware read watchpoint 2: a > > (gdb) c > > Continuing. > > Hardware read watchpoint 2: a > > > > Value = 10 > > 0x080483bd in main () at rw.cpp:11 > > 11 c = a; > > > > Expected result: gdb stops on "b = a" line. > > Actual result: gdb stops on "c = a". I can reproduce this on Debian/unstable. > On Debian GNU/Linux, I can reproduce the problem, but it seems that it > is a side effect of another problem: the breakpoint set by "b main" > stops the program too late. Observe: You included an example of setting the breakpoint by address, but not one of setting by "b main", so I can't guess from your transcript what happened. You also didn't show the disassembly of the function. To answer your question, GDB sets breakpoints on functions based on a combination of prologue analysis and debug info. Here's what mine looks like (note, this is x86_64, not i386): 0x00000000004004a8 : push %rbp 0x00000000004004a9 : mov %rsp,%rbp 0x00000000004004ac : movl $0xa,1049662(%rip) # 0x5008f4 0x00000000004004b6 : mov $0x40061c,%edi 0x00000000004004bb : callq 0x4003e0 0x00000000004004c0 : mov 1049646(%rip),%eax # 0x5008f4 0x00000000004004c6 : mov %eax,1049632(%rip) # 0x5008ec 0x00000000004004cc : mov 1049634(%rip),%eax # 0x5008f4 0x00000000004004d2 : mov %eax,1049624(%rip) # 0x5008f0 0x00000000004004d8 : mov $0x0,%eax 0x00000000004004dd : leaveq 0x00000000004004de : retq "break main" sets the breakpoint at main+4. Which I'd expect, really - it's after the stack frame is created. > ~$ gdb ./rwt > GNU gdb 6.1-debian > 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 "i386-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1". This is a relatively old GDB, and so probably a relatively old GCC. On my installation it behaves as reported. > So I'm guessing that the problem happens because GDB misses the data > write into a in line 7, and thus doesn't take notice that a was > assigned the value 10. That's why it gets confused when "b = a;" > reads from a. It misses it, but shouldn't. When GDB single steps over the temporarily removed breakpoint at "main", it is not updating the values of watchpoints before resuming the instruction. That instruction happened to modify the value behind a read watchpoint. Presumably because trap_expected is set, infrun never calls bpstat_stop_status, so the watchpoint is never checked. Maybe we should separate that code out into a separate function, or maybe we should call it more rigorously. > No, I don't think so. The theory behind the read watchpoint support > on x86 is that GDB should also see the data writes into the watched > variable, and thus always track its current value. This is because > x86 debug hardware doesn't support read watchpoints, it only supports > data-write watchpoints and access (read or write) watchpoints. So GDB > _emulates_ read watchpoints on x86 by setting an access watchpoint, > and monitoring value changes with the code you presented above. > Access watchpoint should trigger when the address is written by the > "a = 10;" line, at which point GDB should get control, record the new > value, then continue the debuggee without announcing the watchpoint > (since the value changed). Later, when "b = a;" reads from a, the > access watchpoint fires again, but this time the value didn't change, > so the watchpoint should be announced. Eli, am I reading breakpoint.c right? It looks like we _always_ ignore changed values for bp_read_watchpoint, which means that the core of GDB does not work on targets which support true read watchpoints. Which IIRC includes S/390, which disabled them for this reason. This should be controlled by an architecture method indicating that there are only access watchpoints. > Here's the GDB session on MS-Windows. As you see, "b main" stops at > line 6, the opening brace of the main function, and then the > watchpoint works as you expected. Probably Windows code requires an additional instruction before "a" can be written to, so you are not stopped on the store instruction as in my example above. -- Daniel Jacobowitz CodeSourcery, LLC