From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2132 invoked by alias); 10 Feb 2014 22:36:09 -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 2120 invoked by uid 89); 10 Feb 2014 22:36:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ve0-f172.google.com Received: from mail-ve0-f172.google.com (HELO mail-ve0-f172.google.com) (209.85.128.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 10 Feb 2014 22:36:06 +0000 Received: by mail-ve0-f172.google.com with SMTP id c14so5543293vea.31 for ; Mon, 10 Feb 2014 14:36:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=T4AZ81yarsp6HAn3EetV9BAvnK5pPjQabwwy1Qd3gnM=; b=IEj2/67FOVezcAIDyFmKjWUkYTO0KhD7/KZfZPYR99uX0V5DgnbXLPlASEyO9R4Dhw oDmsGLG5iLVyD4Tg+CivsHsiLfDx1/S3LbLR2t2fNzt9+aPXn3UejKZnEG76aE6dMeBW 42V6vlQ0OH95qzodo3/URA69lIp/SplB7hLjNJPePzvkoGWuifmiyXGv18yRMs/ptaAo T/f9xDr1fS07C6C71RSCBa2wb4ndoDlXxGHjx2EI4cOI+fGWceKNs+ckG/QjN249tCN9 U9Iwcz3GwZreoNqFzgbBqFzpEGMAbGuLADbwz0zPoo8/oSpdm+10Nqbwn6yK+nMREPPh PyDw== X-Gm-Message-State: ALoCoQltQBYrQ2CeCUbnJ2SqpJ1I3XvwhFyv6vrKgTjd1rioEcrALK8UmmMwlzSNpWICkZ9TKePBhiQyd/d7iaY9S3klwNw0Mu51re+vPB5jaKgITgsrSbXndFBhZKoUB7C2T3JiCXYYEq62AxLWaeksiktBj566Y3GmSUroOCTND4sa5j/SWT6St4xVaVEb1qSZ8dAFhwv+BvaDJgA11MlNs5j1Cec7GA== MIME-Version: 1.0 X-Received: by 10.52.230.105 with SMTP id sx9mr21830789vdc.10.1392071764126; Mon, 10 Feb 2014 14:36:04 -0800 (PST) Received: by 10.52.51.234 with HTTP; Mon, 10 Feb 2014 14:36:04 -0800 (PST) In-Reply-To: References: <1391720136-2121-1-git-send-email-tromey@redhat.com> <1391720136-2121-2-git-send-email-tromey@redhat.com> Date: Mon, 10 Feb 2014 22:36:00 -0000 Message-ID: Subject: Re: [RFC v2 01/38] add "this" pointers to more target APIs From: Doug Evans To: Tom Tromey Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00328.txt.bz2 On Fri, Feb 7, 2014 at 9:19 PM, Doug Evans wrote: > On Thu, Feb 6, 2014 at 12:54 PM, Tom Tromey wrote: >> A subsequent pass introduces delegation helper functions to the target >> API. This delegation is much cleaner if the target_ops pointer is >> directly available at delegation time. >> >> This patch adds the "this" pointer to various to_* methods for this >> purpose. >> >> This updates a number of ports which I am unable to test. Please give >> them a look-over. Any possible problem here is trivial, though, as >> all that is required is adding an argument to a function. > > Hi. > I'm *not* suggesting wholesale changes (babysteps is totally fine with > me), but there's something I'm not sure about. > > I think it was on IRC where there was a discussion of passing the > (pseudo-)vtable pointer as the self/this parameter being less > preferable to passing a more canonical self/this which in turn has the > (pseudo-)vtable pointer. In this case we might not need such a change > until such time as we've already converted to C++ (and thus taking the > next step now could be time best spent elsewhere). My question is to > ask for clarity on where you see the target API headed. Will we need > a more canonical self/this pointer soon(-ish)? As an example (just in case there's some confusion), one thing I'm thinking about is global state used by targets. If, for example, we support multiple remote connections then we're going to have multiple open sockets/descriptors and IWBN if the target_ops methods fetched such things from "self" instead of global variables (*1). I could be missing something of course. --- (*1): I can imagine a temp hack of keeping such global variables around and saving/restoring them when we switch targets (so that we didn't have to update each target_ops function), but that's a bit of work in itself, and I think(!) it would be preferable to skip that step.