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

[Doug Evans <dje at google dot com>]

On Mon, Feb 10, 2014 at 2:36 PM, Doug Evans <dje@google.com> wrote:
> On Fri, Feb 7, 2014 at 9:19 PM, Doug Evans <dje@google.com> wrote:
>> On Thu, Feb 6, 2014 at 12:54 PM, Tom Tromey <tromey@redhat.com> wrote:
>>> A subsequent pass introduces delegation helper functions to the target
>>> API.  This delegation is much cleaner if the target_ops pointer is
>>> directly available at delegation time.
>>>
>>> This patch adds the "this" pointer to various to_* methods for this
>>> purpose.
>>>
>>> This updates a number of ports which I am unable to test.  Please give
>>> them a look-over.  Any possible problem here is trivial, though, as
>>> all that is required is adding an argument to a function.
>>
>> Hi.
>> I'm *not* suggesting wholesale changes (babysteps is totally fine with
>> me), but there's something I'm not sure about.
>>
>> I think it was on IRC where there was a discussion of passing the
>> (pseudo-)vtable pointer as the self/this parameter being less
>> preferable to passing a more canonical self/this which in turn has the
>> (pseudo-)vtable pointer.  In this case we might not need such a change
>> until such time as we've already converted to C++ (and thus taking the
>> next step now could be time best spent elsewhere).  My question is to
>> ask for clarity on where you see the target API headed.  Will we need
>> a more canonical self/this pointer soon(-ish)?
>
> As an example (just in case there's some confusion),
> one thing I'm thinking about is global state used by targets.
> If, for example, we support multiple remote connections then we're
> going to have multiple open sockets/descriptors and IWBN if the
> target_ops methods fetched such things from "self" instead of global
> variables (*1).
>
> I could be missing something of course.
>
> ---
> (*1): I can imagine a temp hack of keeping such global variables
> around and saving/restoring them when we switch targets (so that we
> didn't have to update each target_ops function), but that's a bit of
> work in itself, and I think(!) it would be preferable to skip that
> step.

Gotta love hitting Send one moment too soon.
Apologies for the follow-up.

Another interim solution could be to either use the to_data field of
struct target_ops (I'm not sure if bfd-target.c would need changes) or
add a new field, and have one copy of target_ops per active target.