From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16851 invoked by alias); 10 Feb 2014 23:01:54 -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 16837 invoked by uid 89); 10 Feb 2014 23:01:54 -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-vb0-f52.google.com Received: from mail-vb0-f52.google.com (HELO mail-vb0-f52.google.com) (209.85.212.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 10 Feb 2014 23:01:53 +0000 Received: by mail-vb0-f52.google.com with SMTP id p14so5398360vbm.11 for ; Mon, 10 Feb 2014 15:01:50 -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=oICpc2h6NYPeP9opkOTcfijYiJLZfMOsW5VgKMt137o=; b=c/NuPOfwzgo+3DCrLcnesF7GErkf4E7QoX/gRIfR41X4wdUXMEfhS6Jt4qLovIZPkm 4rQDJP2sDCpSh8Z/TU6sUYM/SNn3cxE8gbpBLMCJVpQRvnbLdIzV0jIdIIEw7VOPgmmD pUfrfczsJtJmnGCMBdK3x7zkqYfZX6tkr1bMpwGT28pKo3e6UJpUXZubz3awiF7spEOB 97n3Jv47boFiGbkIt53/DyC7CFw8Hw6h1sEQQTXnM9LCPnBxisCZP/KHpAcNZ2hSrLFE U1v3/7rlot5dxpe9hq1kMR78rA8Od6TZIYzpqm80o/zexnAvs3U8YPVIiq6IjBIDzElu 7vfA== X-Gm-Message-State: ALoCoQkc0XdqNzwVDY29WxX33jZrwUdzW+wk5TWqw6P3pDWA2L9E00pv/WcXPO6046flTPHT4eRVPzUh6NoniDwilGsFV7eTZOJQb623T4PSyW8Ypqz1uy0YI+EIljXBKdKXyLvcE5AXD1oW8rTHyFVlqJm1lV14gXRlLIeFzMV+aOfPSbhBAaY7zi8WMlr4i9DN4CpQ+2t9B0DyXFparbeXhDfyIj1yVA== MIME-Version: 1.0 X-Received: by 10.52.232.168 with SMTP id tp8mr136319vdc.38.1392073310771; Mon, 10 Feb 2014 15:01:50 -0800 (PST) Received: by 10.52.51.234 with HTTP; Mon, 10 Feb 2014 15:01:50 -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 23:01: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/msg00329.txt.bz2 On Mon, Feb 10, 2014 at 2:36 PM, Doug Evans wrote: > 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. Gotta love hitting Send one moment too soon. Apologies for the follow-up. Another interim solution could be to either use the to_data field of struct target_ops (I'm not sure if bfd-target.c would need changes) or add a new field, and have one copy of target_ops per active target.