From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32427 invoked by alias); 29 Oct 2009 14:58:31 -0000 Received: (qmail 32419 invoked by uid 22791); 29 Oct 2009 14:58:30 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Oct 2009 14:58:26 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 951202BAC96 for ; Thu, 29 Oct 2009 10:58:24 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 46QtGBPHRLoc for ; Thu, 29 Oct 2009 10:58:24 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 5D1CB2BABDF for ; Thu, 29 Oct 2009 10:58:24 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 33C6BF5905; Thu, 29 Oct 2009 15:58:17 +0100 (CET) Date: Thu, 29 Oct 2009 14:58:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: [RFC] design question re: watchpoint target methods Message-ID: <20091029145817.GO24340@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) 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: 2009-10/txt/msg00684.txt.bz2 Hello everyone, Jan said: > [...] I find the single functionality being split into two target > functions (to_stopped_by_watchpoint and to_stopped_data_address) to be > confusing. Chose a new name to easily be able to keep the old > deprecated implementations working until its host maintainers can get > to update them as I cannot even compile some of the host files. I tend to agree because I do not know of any reason why this separation would be needed. Any reason why we should reject Jan's suggestion to have a single target operation instead of two? His proposal is to mark the following methods as deprecated: int (*to_stopped_by_watchpoint) (void); int (*to_stopped_data_address) (struct target_ops *, CORE_ADDR *); And to replace them by by a new operation: enum stopped_by_watchpoint (*to_thread_stopped_by_watchpoint) (ptid_t ptid, CORE_ADDR *data_address_p); Actually, I think that all target_ops operations should take a struct target_ops parameter, even if not needed, at least for consistency, but also to facilitate transitions if this parameter ever becomes needed later on. One difference in the new operation is that it is now explicitly applicable to a specific ptid rather than being implicitly applicable to the current_ptid. enum stopped_by_watchpoint is proposed to be: > +enum stopped_by_watchpoint > + { > + stopped_by_watchpoint_no, > + stopped_by_watchpoint_yes_address_unknown, > + stopped_by_watchpoint_yes_address_known > + }; This is not a critical piece to Jan's suggestion, but I thought I would provide this piece of info, to be complete. -- Joel