From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27913 invoked by alias); 16 Dec 2008 12:16:24 -0000 Received: (qmail 27904 invoked by uid 22791); 16 Dec 2008 12:16:24 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,KAM_MX,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org Received: from imx12.toshiba.co.jp (HELO imx12.toshiba.co.jp) (61.202.160.132) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 16 Dec 2008 12:15:24 +0000 Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id mBGCFFno009964; Tue, 16 Dec 2008 21:15:15 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id mBGCFFpO016516; Tue, 16 Dec 2008 21:15:15 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id XAA16515; Tue, 16 Dec 2008 21:15:15 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id mBGCFE0I007181; Tue, 16 Dec 2008 21:15:14 +0900 (JST) Received: from mx.tjsys.co.jp by toshiba.co.jp id mBGCFE6j007903; Tue, 16 Dec 2008 21:15:14 +0900 (JST) Received: from voltage-out.tjsys.co.jp (voltage-out.tjsys.co.jp [157.79.3.51]) by mx.tjsys.co.jp (8.12.11/8.12.11) with ESMTP id mBGCFEaS013515; Tue, 16 Dec 2008 21:15:14 +0900 (JST) Received: from is-com10 ([157.79.3.71]) by voltage-out.tjsys.co.jp (8.13.1/8.13.1) with SMTP id mBGCF9hW025294; Tue, 16 Dec 2008 21:15:09 +0900 Received: from localhost ([157.79.30.223]) by ims.tjsys.co.jp (iPlanet Messaging Server 5.2 HotFix 2.10 (built Dec 26 2005)) with ESMTP id <0KBY00FJNY15K8@ims.tjsys.co.jp>; Tue, 16 Dec 2008 21:15:05 +0900 (JST) Date: Tue, 16 Dec 2008 12:16:00 -0000 From: Emi SUZUKI Subject: Re: Watchpoint on an unloaded shared library(1) In-reply-to: <20081213150517.GE6866@adacore.com> To: brobecker@adacore.com Cc: gdb-patches@sourceware.org Message-id: <20081216.211520.207584606.emi-suzuki@tjsys.co.jp> MIME-version: 1.0 Content-type: Text/Plain; charset=us-ascii Content-transfer-encoding: 7bit References: <20081120.210657.01365938.emi-suzuki@tjsys.co.jp> <20081213150517.GE6866@adacore.com> X-WAuditID: 0812162115050000018981 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: 2008-12/txt/msg00305.txt.bz2 Hello Joel, Thank you for reviewing! From: Joel Brobecker Subject: Re: Watchpoint on an unloaded shared library(1) Date: Sat, 13 Dec 2008 19:05:17 +0400 > How about replace all the code that's inside > > if (bpt->type == bp_watchpoint || > bpt->type == bp_hardware_watchpoint || > bpt->type == bp_read_watchpoint || > bpt->type == bp_access_watchpoint) > { > [re-create a lot of stuff for our watchpoint...] > > by a call to update_watchpoint (bpt, 1)? Would that work in your case? It works without merging the missing code each other, as long as we don't have to care the hardware watchpoint resource count here: if the user sets other watchpoints while the disabled hardware watchpoints exist, re-enabling the disabled ones might fail out of the shortage of resources. Actually, calling update_watchpoint without resource checking works on almost all the target which has the hardware watchpoint resources, since TARGET_CAN_USE_HARDWARE_WATCHPOINT always returns 1 on those targets. Instead of stop enabling watchpoints in do_enable_breakpoint, out of the watchpoint resources would be reported to the user when GDB actually address to them by target_insert_watchpoint. This mechanism does not work on ppc-linux native target which has DABR: it would just overwrite the register value each time when target_insert_watchpoint is called. However, I've found that the watchpoint resource count checking feature itself does not work at all on that target... ppc_linux_check_watch_resources, which replaces TARGET_CAN_USE_HARDWARE_WATCHPOINT on a ppc-linux target build, never return the negative value. Maybe we should revise them separately... > When I looked at what update_watchpoint does and what do_enable_breakpoint > does for watchpoints, it seemed to me that do_enable_breakpoint was trying > to do the same, except that it was missing a few pieces. Does anybody see > a reason for the code almost-duplication here? I know at least when `update_watchpoint' was introduced: http://sourceware.org/ml/gdb-patches/2008-01/msg00543.html In the thread includes the above mail, Jim Blandy and Vladmir Plus discussed about the timing of refreshing watchpoint expressions and changed some of them. I guess that those codes have got more smilar along with they rebuild the logic. My best regards, -- Emi SUZUKI / emi-suzuki at tjsys.co.jp