From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13442 invoked by alias); 11 Nov 2005 17:39:14 -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 13423 invoked by uid 22791); 11 Nov 2005 17:39:11 -0000 Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (192.114.186.20) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 11 Nov 2005 17:39:11 +0000 Received: from HOME-C4E4A596F7 (IGLD-84-228-244-241.inter.net.il [84.228.244.241]) by nitzan.inter.net.il (MOS 3.6.5-GR) with ESMTP id BXV23231 (AUTH halo1); Fri, 11 Nov 2005 19:39:04 +0200 (IST) Date: Fri, 11 Nov 2005 17:39:00 -0000 Message-Id: From: Eli Zaretskii To: Vladimir Prus CC: gdb@sources.redhat.com In-reply-to: <200511111621.03372.ghost@cs.msu.su> (message from Vladimir Prus on Fri, 11 Nov 2005 16:21:02 +0300) Subject: Re: read watchpoints broken with remote targets? Reply-to: Eli Zaretskii References: <200511111621.03372.ghost@cs.msu.su> X-SW-Source: 2005-11/txt/msg00229.txt.bz2 > From: Vladimir Prus > Date: Fri, 11 Nov 2005 16:21:02 +0300 > > are read watchpoints supposed to work with remote targets? Yes, assuming that the remote stub supports hardware watchpoints. > 1. handle_inferior_event (infrun.c) is called. > > 2. It contains: > int stopped_by_watchpoint = -1; > > 3. The following code is executed: > > if (HAVE_CONTINUABLE_WATCHPOINT) > stopped_by_watchpoint = STOPPED_BY_WATCHPOINT (ecs->ws); > > For remote targets, and for pretty much all other targets, > HAVE_CONTINUABLE_WATCHPOINT is 0, so value of stopped_by_watchpoint > is still -1 > > 4. Function bpstat_stop_status (breakpoint.c) is called, and > stopped_by_watchpoint is passed to it (the value is still -1). > > 5. bpstat_stop_status tries to create a list of stop reasons, by iterating > over all breakpoints and trying to check if that's breakpoint that's > fired. For read wathcpoints we arrive at this: > > if ((b->type == bp_hardware_watchpoint > || b->type == bp_read_watchpoint > || b->type == bp_access_watchpoint) > && !stopped_by_watchpoint) > continue; > > since stepped_by_watchpoint is -1 we continue with the loop body, and > arrive at this: > > bs = bpstat_alloc (b, bs); /* Alloc a bpstat to explain stop */ > > this adds a new element to the list of stop reasons. > > 6. We execute this code: > > if (!target_stopped_data_address (¤t_target, &addr)) > continue; > > since there were no watchpoint, "continue" is executed. But the stop > reasons list still has a new element corresponding to read > watchpoint. > > 7. We return to handle_inhefiour_event, which notices the stop reasons list > and stops stepping. Thanks for the detailed report. I think this should be fixed by explicitly testing for stopped_by_watchpoint being -1, and treating it as if the value were zero. Or perhaps bpstat_stop_status should change its value to zero if it's -1. Can you see if one of these methods solves the problem? > I've fixed this by replacing code in (6) with: > > if (!target_stopped_data_address (¤t_target, &addr)) > { > bs->print_it = print_it_noop; > bs->stop = 0; > continue; > } > > Could somebody comment if this is the right fix? I don't think this is the right fix. In effect, you say that if stopped_by_watchpoint is non-zero, but target_stopped_data_address says there was no watchpoint, let's ignore stopped_by_watchpoint. That's not clean, IMHO. > BTW, HAVE_CONTINUABLE_WATCHPOINT is only set for x86, it seems, so read > watchpoint might be broken for more targets then just remote. Most targets don't support read watchpoints (see my other mail in response to your other message).