From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7350 invoked by alias); 13 Nov 2005 22:38:56 -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 7338 invoked by uid 22791); 13 Nov 2005 22:38:53 -0000 Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 13 Nov 2005 22:38:53 +0000 Received: from HOME-C4E4A596F7 (IGLD-84-228-161-240.inter.net.il [84.228.161.240]) by romy.inter.net.il (MOS 3.5.8-GR) with ESMTP id CZA57483 (AUTH halo1); Mon, 14 Nov 2005 00:38:39 +0200 (IST) Date: Sun, 13 Nov 2005 22:38:00 -0000 Message-Id: From: Eli Zaretskii To: gdb@sources.redhat.com CC: Vladimir Prus In-reply-to: <20051113164546.GA465@nevyn.them.org> (message from Daniel Jacobowitz on Sun, 13 Nov 2005 11:45:48 -0500) Subject: Re: read watchpoints ignored? Reply-to: Eli Zaretskii References: <200511111622.01337.ghost@cs.msu.su> <20051113164546.GA465@nevyn.them.org> X-SW-Source: 2005-11/txt/msg00251.txt.bz2 > Date: Sun, 13 Nov 2005 11:45:48 -0500 > From: Daniel Jacobowitz > Cc: Vladimir Prus , gdb@sources.redhat.com > > I can reproduce this on Debian/unstable. So can I, as I wrote in my reply. > 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 don't need to guess: since you reproduced the problem on your machine (and I on mine), you could just look yourself. I didn't show such a transcript because it was identical to what Vladimir reported, so instead I just said that I see the same on Debian. I don't see why I need to waste bandwidth by posting redundant information, given that the OP's problem is easily reproducible on any similar platform. > You also didn't show the disassembly of the function. Again, there's no need to do that, as your own disassembly clearly shows. I don't understand why are you nitpicking at me. > This is a relatively old GDB, and so probably a relatively old GCC. On > my installation it behaves as reported. So it is on mine, thus the ``relatively old version'' is irrelevant. > > 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", ^^^^^^^^^^ Did you mean ``watchpoint''? If not, I'm afraid I don't follow. > it is not updating the values > of watchpoints before resuming the instruction. That instruction > happened to modify the value behind a read watchpoint. Then that's the bug, I'd say. Do you agree that this is what we should fix to solve this bug? Because the following discussion of problems with read watchpoints is only remotely related to the bug reported by Vladimir. > 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. Sorry, I don't see how the suggestions in your second sentence would solve the problem identified in the first. Could you please explain? > Eli, am I reading breakpoint.c right? Right, and so am I. > 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. We've been through this: it's inaccurate to say that ``GDB does not work on targets which support true read watchpoints.'' A more accurate statement would be ``on targets which support true read watchpoints, GDB does not announce read watchpoints when the watched value changes,'' which is quite a different story, and a fairly rare case. If someone finds a way to announce a read watchpoint when the value changed on a target that supports that, without losing support for read watchpoints on x86 (which is by far the most popular platform these days), I'll gladly agree to such a change. IIRC, until now no one did find how to do that. I object to fixing read watchpoints in such rare situations (i.e., when the data is only read, not written, but the value still changes as a side effect) at a price of losing read watchpoints on x86. The solution proposed by Vladimir would do precisely that, so I don't think we should accept it. > This should be controlled by an architecture method indicating that > there are only access watchpoints. And then what? disable `rwatch'? I object to such ``solution'', since the emulated read watchpoints proved to be most useful to me since the code we discuss was introduced.