Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.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
Date: Tue, 29 Jul 2014 21:32:00 -0000	[thread overview]
Message-ID: <CADPb22RQKAYSp_7FJfe_ygu-f5NkLtE=9URg1tRR5dGi4CzDdA@mail.gmail.com> (raw)
In-Reply-To: <87y4vcawjd.fsf@fleche.redhat.com>

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?


  reply	other threads:[~2014-07-29 21:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-18 19:27 Tom Tromey
2014-07-18 19:27 ` [PATCH 2/4] simplify target_is_pushed Tom Tromey
2014-07-29 13:22   ` Joel Brobecker
2014-07-29 15:16     ` Tom Tromey
2014-07-18 19:27 ` [PATCH 1/4] move core_bfd to program space Tom Tromey
2014-07-18 19:45 ` [PATCH 3/4] add to_identity Tom Tromey
2014-07-29 14:56   ` Joel Brobecker
2014-07-29 15:11     ` Tom Tromey
2014-07-18 20:44 ` [PATCH 4/4] convert corelow to to_xclose Tom Tromey
2014-07-29 15:11 ` [PATCH 0/4] baby step toward multi-target Pedro Alves
2014-07-29 15:15   ` Tom Tromey
2014-07-29 16:32     ` Pedro Alves
2014-07-29 19:04       ` Tom Tromey
2014-07-29 21:32         ` Doug Evans [this message]
2014-08-11  5:54           ` Doug Evans
2014-07-29 15:40   ` Doug Evans
2014-08-10 20:02 ` Doug Evans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CADPb22RQKAYSp_7FJfe_ygu-f5NkLtE=9URg1tRR5dGi4CzDdA@mail.gmail.com' \
    --to=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox