From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21878 invoked by alias); 29 May 2018 03:13:43 -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 21861 invoked by uid 89); 29 May 2018 03:13:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=cheap X-HELO: gateway31.websitewelcome.com Received: from gateway31.websitewelcome.com (HELO gateway31.websitewelcome.com) (192.185.143.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 May 2018 03:13:40 +0000 Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway31.websitewelcome.com (Postfix) with ESMTP id E67E29B12 for ; Mon, 28 May 2018 22:13:38 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id NV4sfCeW9kBj6NV4sfhhAr; Mon, 28 May 2018 22:13:38 -0500 X-Authority-Reason: nr=8 Received: from 174-29-44-154.hlrn.qwest.net ([174.29.44.154]:49164 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fNV4s-002FUd-Lp; Mon, 28 May 2018 22:13:38 -0500 From: Tom Tromey To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 4/4] Introduce class target_stack References: <20180528161041.32497-1-palves@redhat.com> <20180528161041.32497-5-palves@redhat.com> Date: Tue, 29 May 2018 11:34:00 -0000 In-Reply-To: <20180528161041.32497-5-palves@redhat.com> (Pedro Alves's message of "Mon, 28 May 2018 17:10:41 +0100") Message-ID: <87h8mrxify.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Source-L: No X-Exim-ID: 1fNV4s-002FUd-Lp X-Source-Sender: 174-29-44-154.hlrn.qwest.net (bapiya) [174.29.44.154]:49164 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-SW-Source: 2018-05/txt/msg00751.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> The problem then is in finding a target's "beneath" target, if we Pedro> consider that for some target_ops types, we'll be sharing a Pedro> single target_ops instance between several inferiors. For Pedro> example, so far, I found no need to have multiple instances of Pedro> the spu_multiarch_target / exec_target / dummy_target targets. Is it the case that sometimes a particular target_ops instance will have to be shared among multiple target stacks? If so, then this all makes sense to me. If not, then it seems maybe slightly off, because then if you need to add state to some existing target_ops, you will have to check whether it is shareable and then ensure it is unshared -- does this make sense? But on the other hand, an instance of something like dummy_target should be cheap (sizeof == 24 here). So maybe a simpler rule is available. On the third hand, it's only slightly off, and I don't want to get in the way of this important project; but I would still like to understand. Pedro> +/* The target stack. */ Pedro> +static target_stack g_target_stack; As an aside, I often wonder about blank lines between comments and definitions. I prefer not to have them, though not for any actual reason. But some spots have them and some do not, so in practice what I do is either follow the local style; or leave the blank line out if I think I can; or else feel guilty since I vaguely recall there was a rule to have one and so put it in even though I'd rather not. Pedro> + Note that rather than allow an empty stack, we always have the Pedro> + dummy target at the bottom stratum, so we can call the function Pedro> + vectors without checking them. */ Probably just "methods" rather than "function vectors". Tom