This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 0/4] baby step toward multi-target
- From: Doug Evans <dje at google dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Pedro Alves <palves at redhat dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Tue, 29 Jul 2014 14:08:04 -0700
- Subject: Re: [PATCH 0/4] baby step toward multi-target
- Authentication-results: sourceware.org; auth=none
- References: <1405711635-1102-1-git-send-email-tromey at redhat dot com> <53D7AE46 dot 8080303 at redhat dot com> <87lhrccja2 dot fsf at fleche dot redhat dot com> <53D7C8D8 dot 30104 at redhat dot com> <87y4vcawjd dot fsf at fleche dot redhat dot 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?