Message ID | m3wqaf8tcr.fsf@sspiff.org |
---|---|
State | New, archived |
Headers |
Received: (qmail 29689 invoked by alias); 11 Aug 2014 05:54:23 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 29674 invoked by uid 89); 11 Aug 2014 05:54:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f42.google.com Received: from mail-pa0-f42.google.com (HELO mail-pa0-f42.google.com) (209.85.220.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 11 Aug 2014 05:54:20 +0000 Received: by mail-pa0-f42.google.com with SMTP id lf10so10529798pab.15 for <gdb-patches@sourceware.org>; Sun, 10 Aug 2014 22:54:18 -0700 (PDT) X-Received: by 10.68.220.34 with SMTP id pt2mr18828009pbc.47.1407736458724; Sun, 10 Aug 2014 22:54:18 -0700 (PDT) Received: from seba.sebabeach.org.gmail.com (173-13-178-50-sfba.hfc.comcastbusiness.net. [173.13.178.50]) by mx.google.com with ESMTPSA id gm1sm10144515pbc.40.2014.08.10.22.54.17 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Aug 2014 22:54:18 -0700 (PDT) From: Doug Evans <xdje42@gmail.com> To: Tom Tromey <tromey@redhat.com> Cc: Pedro Alves <palves@redhat.com>, gdb-patches <gdb-patches@sourceware.org> Subject: Re: [PATCH 0/4] baby step toward multi-target 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> <CADPb22RQKAYSp_7FJfe_ygu-f5NkLtE=9URg1tRR5dGi4CzDdA@mail.gmail.com> Date: Sun, 10 Aug 2014 22:53:40 -0700 In-Reply-To: <CADPb22RQKAYSp_7FJfe_ygu-f5NkLtE=9URg1tRR5dGi4CzDdA@mail.gmail.com> (Doug Evans's message of "Tue, 29 Jul 2014 14:08:04 -0700") Message-ID: <m3wqaf8tcr.fsf@sspiff.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes |
Commit Message
Doug Evans
Aug. 11, 2014, 5:53 a.m. UTC
Doug Evans <dje@google.com> writes: > On Tue, Jul 29, 2014 at 10:45 AM, Tom Tromey <tromey@redhat.com> 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? Regarding avoiding looking at the payload ... I noticed this in 4/4. I think(!) it's unrelated, though I'm still unclear on what you're referring to. At any rate, the following is odd. Several "methods" take a "self" or "ops" pointer but then don't use it and instead go search the target stack for what I'd expect to be the same thing. E.g., The intuitive thing to do here is assert t is a core ops, and then use it. Instead the code calls get_core_target_ops. Why? I realize you mentioned in another email that you probably wouldn't be inclined to check this in. But if corelow is to be the example on which other targets are based I'd like to understand all the oddities I find. [Maybe the above is just oversight, in which case no worries. But gdb's target support isn't always intuitive, and I don't always trust my intuition with it.]
diff --git a/gdb/corelow.c b/gdb/corelow.c index 1775a66..212665d 100644 --- a/gdb/corelow.c +++ b/gdb/corelow.c @@ -611,7 +639,9 @@ get_core_registers (struct target_ops *ops, static void core_files_info (struct target_ops *t) { - print_section_info (core_data, core_bfd); + struct core_target_ops_with_data *cops = get_core_target_ops (); + + print_section_info (&cops->core_data, core_bfd); } struct spuid_list