From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13625 invoked by alias); 10 Aug 2014 20:02: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 13607 invoked by uid 89); 10 Aug 2014 20:02:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f50.google.com Received: from mail-pa0-f50.google.com (HELO mail-pa0-f50.google.com) (209.85.220.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sun, 10 Aug 2014 20:02:44 +0000 Received: by mail-pa0-f50.google.com with SMTP id et14so9936604pad.37 for ; Sun, 10 Aug 2014 13:02:42 -0700 (PDT) X-Received: by 10.68.200.101 with SMTP id jr5mr37599608pbc.36.1407700962795; Sun, 10 Aug 2014 13:02:42 -0700 (PDT) Received: from seba.sebabeach.org.gmail.com (173-13-178-50-sfba.hfc.comcastbusiness.net. [173.13.178.50]) by mx.google.com with ESMTPSA id qy8sm49547569pab.12.2014.08.10.13.02.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Aug 2014 13:02:41 -0700 (PDT) From: Doug Evans To: Tom Tromey 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> Date: Sun, 10 Aug 2014 20:02:00 -0000 In-Reply-To: <1405711635-1102-1-git-send-email-tromey@redhat.com> (Tom Tromey's message of "Fri, 18 Jul 2014 13:27:11 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00178.txt.bz2 Tom Tromey writes: > My multi-target branch is basically dead, I think, mostly due to heavy > conflicts with all the other target changes that have happened in the > meantime. This is an important bit of functionality that needs to be done. Since we just released 7.8, and in order to prevent such things happening again, I think it would be reasonable to put more resources into getting this done, and delay other things for awhile. [Assuming various factors like it won't take an inordinate amount of time, and the end result is the more preferred one, and probably a few others :-).] $0.02 > However recently I realized that there is a less invasive > way to achieve many of the same effects, and a way to salvage some of > the smaller cleanups done there. > > In particular on the branch I attempted to split target_ops into a > vtable-like object and a target state object. As you might imagine > this patch touches a large amount of code and is hard both to keep up > to date, and to test. That was my understanding of where we were headed. > This little series, on the other hand, takes a less invasive approach. > The idea here is that rather than doing a huge target_ops split, > instead just sometimes make copies of the target_ops when pushing. > This lets the copies keep their own state; copies are needed in the > long run because multiple target stacks will be active and a given > target_ops only has one "beneath" pointer. Which version of the long run? Wouldn't dynamic properties of the object be kept in the object and not the vtable? Or is some custom dynamic interitance being done here? I can imagine that being useful to facilitate inserting debug targets into the mix. By way of analogy, I'd be curious how this would be done in c++. [Just trying to understand the situation better.] > Here corelow is used as the example of how to do a conversion. > There's a bit of cleanup and infrastructure initially, and then the > final patch moves the corelow global state into a new subclass of > target_ops, which is instantiated and pushed. > > If this approach seems reasonable then it's not too hard to pull over > some of the other target conversions from the branch. > > This series also shows the spots to change if you want to make the > debug target wrap each stratum in the target stack -- each wrapping > debug target would be to_xclose-ish, and spots like target_is_pushed > would be taught to unwrap. > > Built and regtested on x86-64 Fedora 20.