Re: [RFC v2 01/38] add "this" pointers to more target APIs

[Doug Evans <dje@google.com>]

On Wed, Feb 12, 2014 at 11:56 AM, Tom Tromey <tromey@redhat.com> wrote:
> 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).
>[...]
> 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.

Ah, so this series is just an interim step, and a follow-up will
replace "struct target_ops *self" with "struct foo *self" with foo
containing "struct target_ops *".

Thanks for the clarification.