From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7099 invoked by alias); 9 Sep 2008 05:19:46 -0000 Received: (qmail 7089 invoked by uid 22791); 9 Sep 2008 05:19:45 -0000 X-Spam-Check-By: sourceware.org Received: from smtp1.dnsmadeeasy.com (HELO smtp1.dnsmadeeasy.com) (205.234.170.134) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 09 Sep 2008 05:18:54 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id 41F0E321375 for ; Tue, 9 Sep 2008 05:18:53 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [173.8.135.205]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP for ; Tue, 9 Sep 2008 05:18:53 +0000 (UTC) Received: from silver64.hq2.avtrex.com ([192.168.7.226]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Sep 2008 22:18:50 -0700 Message-ID: <48C60739.8070000@avtrex.com> Date: Tue, 09 Sep 2008 05:19:00 -0000 From: David Daney User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Adding watchpoint functions to target vector vs. TARGET*WATCHPOINT macros Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00050.txt.bz2 In working on adding hardware watch register support to mips*-linux, I have encountered a small issue. Back in: http://sourceware.org/ml/gdb-patches/2008-04/msg00443.html Daniel pointed out that all the watch related functions could be added directly to the target vector instead of writing target specific TARGET*WATCHPOINT macros. While this is true, there is a small drawback. The target vector is not installed until the inferior is started, so any watches added before this happens end up being soft-watches. If the various TARGET*WATCHPOINT macros are defined instead, hardware watchpoints can be added even if the inferior has not been started. This scares me a little as it seems that they may end up triggering in the shell that is starting the inferior. Ideally in when the first resume() is issued to the inferior the watchpoints would be re-evaluated to see if some (or all) of them could be converted to hardware watchpoints. There might have to be an additional target hook to allow for this. For the short term I think I will stick to adding the watch functions to the target vector, but I am interested in feedback on the merits of either re-evaluating the watchpoints or using the TARGET*WATCHPOINT macros Thanks, David Daney