From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21171 invoked by alias); 29 Jul 2014 17:45:48 -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 21150 invoked by uid 89); 29 Jul 2014 17:45:48 -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 (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 29 Jul 2014 17:45:47 +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 s6THjjVR002961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 29 Jul 2014 13:45:45 -0400 Received: from barimba (ovpn-113-151.phx2.redhat.com [10.3.113.151]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6THjhrp005680 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Tue, 29 Jul 2014 13:45:44 -0400 From: Tom Tromey To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 0/4] baby step toward multi-target References: <1405711635-1102-1-git-send-email-tromey@redhat.com> <53D7AE46.8080303@redhat.com> <87lhrccja2.fsf@fleche.redhat.com> <53D7C8D8.30104@redhat.com> Date: Tue, 29 Jul 2014 19:04:00 -0000 In-Reply-To: <53D7C8D8.30104@redhat.com> (Pedro Alves's message of "Tue, 29 Jul 2014 17:16:24 +0100") Message-ID: <87y4vcawjd.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: 2014-07/txt/msg00763.txt.bz2 Tom> However, it's probably useful as a starting point for the next attempt Tom> at multi-target. In particular it's much less invasive than the earlier Tom> approach, and the "convert current_target to be a pointer" patch (the Tom> biggest one) was mostly done with a perl one-liner. Pedro> Yeah. Pedro> Hmm, kind of orthogonal, but not really, I wonder how far are we Pedro> to getting rid of the remaining target stack annoyances. Like: Pedro> #1 - Convert the remaining data fields to methods. That seems it'll Pedro> just be boring work. Agreed. Pedro> #2 - making the debug target a wrapping target around each Pedro> target layer (as you suggested elsewhere). That'll require Pedro> make-target-delegates hacking. And a bit of hacking in the same spots touched by the "identity" patch in this series. It doesn't seem very hard. Pedro> That'd then make it possible to: Pedro> #3 - eliminate the squashed current_target, replacing it with a pointer Pedro> to the topmost target in the stack (mostly the same as your Pedro> perl one-liner). Pedro> Is that in line with what you've been thinking? I'm wondering whether Pedro> you found out in the more invasive branch that it's useful if Pedro> current_target is more than a struct target_ops pointer ? Pedro> (or "struct target *" after vtable-ification.) I think it's reasonable to try to get there. Certainly at this point the squashed target is not extremely useful. You can see this by looking at how few uses of INHERIT remain. This would also let us zap the uses of "current_target.beneath" that we discussed yesterday. The more invasive branch took a different approach to target identity. Rather than the to_identity field, it split target_ops into a const vtable part and a payload part. Then it aimed to require all targets to instantiate a new object. This obviously has to touch a lot of code. And, it runs into some difficulties where the target code must work with uninstantiated targets. I don't think this is as much of an issue on the new branch. At least from what I recall the uninstantiated business isn't a big issue because this only affects a subset of methods, which can simply avoid looking at the payload. Also perhaps the target delegation changes cleaned things up a bit too, I forget. On the new branch, having current_target be a pointer is preferable just because it makes target-swapping cheap -- it just means redirecting two pointers (it could be one pointer, but I chose to keep current_target a global, always pointing into the current target_stack object; this means the target stack can be opaque). I didn't consider making current_target have some other type. Tom