From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9403 invoked by alias); 22 Feb 2010 19:24:28 -0000 Received: (qmail 9391 invoked by uid 22791); 22 Feb 2010 19:24:27 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS_WEB,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 22 Feb 2010 19:24:20 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0KY900I00CEMGV00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Mon, 22 Feb 2010 21:24:18 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.228.213.68]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KY900H11CKGTS40@a-mtaout22.012.net.il>; Mon, 22 Feb 2010 21:24:18 +0200 (IST) Date: Mon, 22 Feb 2010 19:24:00 -0000 From: Eli Zaretskii Subject: Re: read watchpoints don't work on targets that support read watchpoints In-reply-to: <201002212147.44779.pedro@codesourcery.com> To: Pedro Alves Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83r5odm5un.fsf@gnu.org> References: <201002180111.31520.pedro@codesourcery.com> <83aav6xuag.fsf@gnu.org> <83635ty1g2.fsf@gnu.org> <201002212147.44779.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-02/txt/msg00550.txt.bz2 > From: Pedro Alves > Date: Sun, 21 Feb 2010 21:47:44 +0000 > > I think we're on the right track, but the logic can > be simplified further: > > If we're watchpoint the memory for both reads and writes, then > apply the only-if-changed logic. Otherwise, report the watchpoint > unconditionally. The former can happen either when the user set an > access or write watchpoint at the same memory as the read > watchpoint, or, when GDB falls back to emulating read watchpoints > with access watchpoints. Agreed. > WDYT? I like it, but I have a few comments and questions: > + /* If trying to set a read-watchpoint, and it turns out it's not > + supported, try emulating one with an access watchpoint. */ > + if (val == 1 && bpt->watchpoint_type == hw_read) > + { > + struct bp_location *loc, **loc_temp; > + > + /* But don't try to insert it, if there's already another > + hw_access location that would be considered a duplicate > + of this one. */ What does the last comment above mean for the use-case where I set a read watchpoint and an access watchpoint at the same address (but with different conditions)? I probably am missing something, because the above seems to say this use will be impossible? > + if (bl->watchpoint_type == hw_read) > + { > + CORE_ADDR addr; > + int res; > + > + /* A real read watchpoint. Check if we're also > + trapping the same memory for writes. */ > + > + res = target_stopped_data_address (¤t_target, > + &addr); > + /* We can only find a read watchpoint triggering > + if we know the address that trapped. We > + shouldn't get here otherwise. */ > + gdb_assert (res); > + > + ALL_BREAKPOINTS (b) > + if (breakpoint_enabled (b) > + && (b->type == bp_hardware_watchpoint > + || b->type == bp_access_watchpoint)) Why do you need to scan ALL_BREAKPOINTS HERE? Can't you scan only the list returned by watchpoints_triggered? > + /* Exact match not required. Within range > + is sufficient. */ > + for (loc = b->loc; loc; loc = loc->next) > + if (target_watchpoint_addr_within_range > + (¤t_target, > + addr, > + loc->address, > + loc->length)) And why are we checking watchpoints that couldn't have triggered, because they watch a different, albeit close, address? What would be the use-case where such a watchpoint could be relevant to deciding which watchpoint to announce?