From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85299 invoked by alias); 25 May 2018 13:49:55 -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 85186 invoked by uid 89); 25 May 2018 13:49:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=palves X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 25 May 2018 13:49:53 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BB6B1401EF25 for ; Fri, 25 May 2018 13:49:51 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1F9F88445D; Fri, 25 May 2018 13:49:50 +0000 (UTC) Subject: Re: [RFC][PATCH v2] Consolidate gdbserver global variables To: "Frank Ch. Eigler" References: <3153f899-a653-9372-72fd-25ea874f7d3c@redhat.com> <44875dda-adc6-d9a4-940c-0c27aeac574b@redhat.com> <6a41763b-6949-2d32-37fa-9d3f1afceec1@redhat.com> <7d9764b6-d95a-96b4-b064-27ce539327cf@redhat.com> <9988957e-3bf8-cbe8-6c08-58706b11bd60@redhat.com> <87in7zjmxk.fsf@redhat.com> Cc: Stan Cox , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <2c497de4-eec5-b66c-5569-e9b45c5e7b77@redhat.com> Date: Fri, 25 May 2018 14:31:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <87in7zjmxk.fsf@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-05/txt/msg00664.txt.bz2 On 05/07/2018 08:16 PM, Frank Ch. Eigler wrote: > > palves wrote: > >> [...] >> Some comments more. I still have some design reservations. >> It seems to me that simply making some of the globals be >> per client along won't work correctly. Particularly, the >> cases where the globals are used in the backends. >> [...] > > I don't want to speak for Stan here, ;-) > but I suspect all this is about is > the breaking up of the multi-client work along the patchset path your > requested. Yup, indeed backends have to do the logical 'union' of the > work that all the clients request, and each client interface will have > to filter the notifications correspondingly to undo the 'union'. Note that in some cases it's not just even filtering. Globals can control modes of operation, like the cs->non_stop case I pointed out in a previous review. > > But all that is in a separate patch; this part seems to simply > reorganize the globals in preparation for that, as you asked. Right, but it doesn't hurt to think about the plan for the issues I pointed out a bit, since it may avoid churn in a direction that we may not want. In the original version of the patch, when macros were used, these references to client_state fields from the backends were pretty much invisible (because of the macros), so it would be unsurprising to me if the full multi-client prototype that is based on the macros version does not consider these issues. I'll go look at the updated patch. Thanks, Pedro Alves