From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1316 invoked by alias); 29 Jul 2014 21:08: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 1294 invoked by uid 89); 29 Jul 2014 21:08: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-vc0-f175.google.com Received: from mail-vc0-f175.google.com (HELO mail-vc0-f175.google.com) (209.85.220.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 29 Jul 2014 21:08:06 +0000 Received: by mail-vc0-f175.google.com with SMTP id ik5so449602vcb.34 for ; Tue, 29 Jul 2014 14:08:04 -0700 (PDT) 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=NVC76EktI7muZ9vV8PEfiYzCMhtXNWmPAyK/AQ9HgXw=; b=bYdST5PdoRmVpVboyrUOaIOabSw2RkPG1/NKNKsGtDU9+CXPQWsFxWCk725e+sjL6A oLvntw1HdrMlOwmcSkafc2Lbo/WcoVzcvEt9BJHURVoRDYws7FYQBZELNjiFegVfYvn6 e3z/ZoeJ0GR50YcucFEKXz2/wqHQgNLPOoKoLj2yZ2Ok9cCqwCWTkPCOIfnn14oeq+Fk RSAyHdL9jvEmQzCaqj4t4hYvFYXTIYiPFQEvR8kkoKjOVrAhDpAVunu3QonjFFq511St nH+56rLCnn/qHb8NMj6+hx6e6HOhkUa6ALadHSyDPDA98UAS/iSN2lvrHJjbgAUmDt8U 0KeA== X-Gm-Message-State: ALoCoQlT/PImxf/Pm+cDiuQUJCioWQjWc8EIectw1dAYJOPvtJUoSe3uWKcnjY7YE8FKrnDfv0hJ MIME-Version: 1.0 X-Received: by 10.52.157.41 with SMTP id wj9mr3812245vdb.1.1406668084108; Tue, 29 Jul 2014 14:08:04 -0700 (PDT) Received: by 10.52.28.233 with HTTP; Tue, 29 Jul 2014 14:08:04 -0700 (PDT) In-Reply-To: <87y4vcawjd.fsf@fleche.redhat.com> References: <1405711635-1102-1-git-send-email-tromey@redhat.com> <53D7AE46.8080303@redhat.com> <87lhrccja2.fsf@fleche.redhat.com> <53D7C8D8.30104@redhat.com> <87y4vcawjd.fsf@fleche.redhat.com> Date: Tue, 29 Jul 2014 21:32:00 -0000 Message-ID: Subject: Re: [PATCH 0/4] baby step toward multi-target From: Doug Evans To: Tom Tromey Cc: Pedro Alves , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00770.txt.bz2 On Tue, Jul 29, 2014 at 10:45 AM, Tom Tromey wrote: > The more invasive branch took a different approach to target identity. > Rather than the to_identity field, it split target_ops into a const > vtable part and a payload part. Then it aimed to require all targets to > instantiate a new object. Hi. I'd like to understand this more. By way of analogy, are you talking about something akin to RTTI, or something else? [How would the problem of target identity be solved if one went with the "all targets instantiate a new object" approach?] > This obviously has to touch a lot of code. And, it runs into some > difficulties where the target code must work with uninstantiated > targets. By way of analogy, is all such code akin to static methods? > I don't think this is as much of an issue on the new branch. > At least from what I recall the uninstantiated business isn't a big > issue because this only affects a subset of methods, which can simply > avoid looking at the payload. Avoid looking at the payload how? Do you mean said "methods" would get passed an argument they are explicitly not supposed to touch?