From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3466 invoked by alias); 12 Dec 2013 02:46:28 -0000 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 Received: (qmail 3455 invoked by uid 89); 12 Dec 2013 02:46:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Dec 2013 02:46:27 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBC2kP2K029493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 11 Dec 2013 21:46:25 -0500 Received: from barimba (ovpn-113-93.phx2.redhat.com [10.3.113.93]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rBC2kNbS008162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 11 Dec 2013 21:46:24 -0500 From: Tom Tromey To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v4 3/9] add target method delegation References: <1382464769-2465-1-git-send-email-tromey@redhat.com> <1382464769-2465-4-git-send-email-tromey@redhat.com> <526E8B54.8040104@redhat.com> <87eh75cmig.fsf@fleche.redhat.com> <87a9htcme3.fsf@fleche.redhat.com> <87habz7q6g.fsf@fleche.redhat.com> <527D1A84.9040106@redhat.com> <87lhzr11wz.fsf@fleche.redhat.com> Date: Thu, 12 Dec 2013 02:46:00 -0000 In-Reply-To: <87lhzr11wz.fsf@fleche.redhat.com> (Tom Tromey's message of "Wed, 11 Dec 2013 15:02:52 -0700") Message-ID: <87a9g623cw.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-12/txt/msg00460.txt.bz2 Pedro> target_wait would then be: Tom> [...] Pedro> WDYT? Tom> It seems good to me. I tinkered with this a little and, not liking the result much, spent some more time thinking about it. Specifically, I considered how I would write this in C++. There I think what I would do is have a pure-virtual target base class. This corresponds to target_ops. Then, I'd have a "delegator" subclass from which all ordinary targets would derive. This class would implement each delegatable method by unconditionally forwarding to "beneath": struct target_delegator : public target_ops { // e.g. int has_all_memory () { return beneath->has_all_memory(); } }; I'd make the dummy target implement all methods using some baseline behavior. struct dummy_target : public target_ops { int has_all_memory () { return 0; } }; Finally, individual targets would derive from target_delegator and override methods as appropriate. Translating back to gdb, rather than implement target_delegate_* functions that search through the target stack, what if we implement the appropriate dummy fallback functions, and have delegation functions that call via "beneath"? We can fill in the fields of target_ops in complete_target_initialization. Since this is very repetitive I would consider doing it via a ".defs" file and then some macrology to reduce the amount of boilerplate. Let me know what you think. I'll experiment with it a bit tomorrow. Tom