From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6983 invoked by alias); 12 Feb 2014 19:56: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 6974 invoked by uid 89); 12 Feb 2014 19:56:55 -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,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 ESMTP; Wed, 12 Feb 2014 19:56:54 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1CJuo64023090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Feb 2014 14:56:51 -0500 Received: from barimba (ovpn-113-148.phx2.redhat.com [10.3.113.148]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1CJumVl007234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 12 Feb 2014 14:56:49 -0500 From: Tom Tromey To: Doug Evans Cc: gdb-patches Subject: Re: [RFC v2 01/38] add "this" pointers to more target APIs References: <1391720136-2121-1-git-send-email-tromey@redhat.com> <1391720136-2121-2-git-send-email-tromey@redhat.com> Date: Wed, 12 Feb 2014 19:56:00 -0000 In-Reply-To: (Doug Evans's message of "Mon, 10 Feb 2014 14:36:04 -0800") Message-ID: <87ha84t88v.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-02/txt/msg00433.txt.bz2 Doug> As an example (just in case there's some confusion), Doug> one thing I'm thinking about is global state used by targets. Doug> If, for example, we support multiple remote connections then we're Doug> going to have multiple open sockets/descriptors and IWBN if the Doug> target_ops methods fetched such things from "self" instead of global Doug> variables (*1). Doug> I could be missing something of course. Doug> --- Doug> (*1): I can imagine a temp hack of keeping such global variables Doug> around and saving/restoring them when we switch targets (so that we Doug> didn't have to update each target_ops function), but that's a bit of Doug> work in itself, and I think(!) it would be preferable to skip that Doug> step. My plan is outlined on the multi-target wiki page and on the patches on the corresponding branch. The wiki page is here: https://sourceware.org/gdb/wiki/MultiTarget Basically the question is whether it is better to turn target_ops into a real vtable and separate the vtable bits from the state bits. I think this is undeniably cleaner. One concrete benefit of the cleanliness aspect is that it exposes the API difficulties around to_open; namely that we need to properly instantiate target objects in spots like find_default_run_target. This is not properly handled on the branch. But, as I said, it is more typing to do this conversion, especially as I'll now have to redo it, which is somewhat demotivating. Not to mention that this would be another sub-series requiring unusual amounts of testing, as it touches code everywhere. And, it isn't strictly necessary, as to_data can be used. And, if I were to do it again, I'd probably do it a bit differently. So I'm not sure. There really aren't that many targets to convert, in the sense that being target async capable is a prerequisite for multi-target; and if a target's maintainer hasn't bothered to do this conversion, then it can be ignored. Also, *-nat targets do not require a state conversion, as in the gdb design they are inherently singletons. I believe this leaves remote (largely done and merged; though see the wiki), corelow (done on the branch), ctf, tfile, and record. I have not yet converted the latter three. As far as the target stack goes, the branch makes the notion of a target stack explicit, and attaches the target stack to the program space. Switching progspaces also switches target stacks. I'm happy with this approach, though of course it is still too early to know whether it has an undiscovered flaw. An individual stratum in a given target stack has access to its own data, on the branch by subclassing gdb_target, but see above. Tom