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

[Tom Tromey <tromey@redhat.com>]

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).

Doug> I could be missing something of course.

Doug> ---
Doug> (*1): I can imagine a temp hack of keeping such global variables
Doug> around and saving/restoring them when we switch targets (so that we
Doug> didn't have to update each target_ops function), but that's a bit of
Doug> work in itself, and I think(!) it would be preferable to skip that
Doug> step.

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.

There really aren't that many targets to convert, in the sense that
being target async capable is a prerequisite for multi-target; and if a
target's maintainer hasn't bothered to do this conversion, then it can
be ignored.  Also, *-nat targets do not require a state conversion, as
in the gdb design they are inherently singletons.  I believe this leaves
remote (largely done and merged; though see the wiki), corelow (done on
the branch), ctf, tfile, and record.  I have not yet converted the
latter three.

As far as the target stack goes, the branch makes the notion of a target
stack explicit, and attaches the target stack to the program space.
Switching progspaces also switches target stacks.  I'm happy with this
approach, though of course it is still too early to know whether it has
an undiscovered flaw.  An individual stratum in a given target stack has
access to its own data, on the branch by subclassing gdb_target, but see
above.

Tom