From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1714 invoked by alias); 29 Jul 2014 16:23:33 -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 20695 invoked by uid 89); 29 Jul 2014 16:16:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 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 16:16:27 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6TGGQZN017160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 29 Jul 2014 12:16:26 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6TGGOPi000439; Tue, 29 Jul 2014 12:16:25 -0400 Message-ID: <53D7C8D8.30104@redhat.com> Date: Tue, 29 Jul 2014 16:32:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 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> <53D7AE46.8080303@redhat.com> <87lhrccja2.fsf@fleche.redhat.com> In-Reply-To: <87lhrccja2.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-07/txt/msg00760.txt.bz2 On 07/29/2014 03:49 PM, Tom Tromey wrote: > However, it's probably useful as a starting point for the next attempt > at multi-target. In particular it's much less invasive than the earlier > approach, and the "convert current_target to be a pointer" patch (the > biggest one) was mostly done with a perl one-liner. Yeah. Hmm, kind of orthogonal, but not really, I wonder how far are we to getting rid of the remaining target stack annoyances. Like: #1 - Convert the remaining data fields to methods. That seems it'll just be boring work. #2 - making the debug target a wrapping target around each target layer (as you suggested elsewhere). That'll require make-target-delegates hacking. That'd then make it possible to: #3 - eliminate the squashed current_target, replacing it with a pointer to the topmost target in the stack (mostly the same as your perl one-liner). Is that in line with what you've been thinking? I'm wondering whether you found out in the more invasive branch that it's useful if current_target is more than a struct target_ops pointer ? (or "struct target *" after vtable-ification.) Thanks, Pedro Alves