Re: [rfc] Introduce "target_gdbarch" variable

[Joel Brobecker <brobecker@adacore.com>]

> "remote" uses gdbarch to store properties of the connection to its
> targets.  For example, the layout of the "g" packet is stored there.
> Even in a scenario where we have per-thread / per-frame architectures,
> those properties will still stay invariant for one target.
[...]
> It may be that at some point, this will need to be fundamentally
> changed anyway, e.g. because the association of one single solib
> method to one target may no longer be sufficient.  At this point,
> those properties might have to be moved out of gdbarch completely.

I was thinking exactly this as I was reading your explaination!
As struct target seems indeed the way to go, eventually.

> But even so, I think moving them to target_gdbarch (even if in the
> long run this turns out to be just a temporary solution) would be
> helpful in the short run, as it allows adding per-frame architecture
> support without major up-front changes to the solib code ...

I agree it's helpful, and the cost of having to another global doesn't
seem very high (at least at first sight! I won't be surprised if we
run into trouble later because of some little detail we forgot, but
I'm sure we can deal with them when they arise). I know others such
as Daniel know this code a lot better than I do, though. It'd be nice
if they could comment as well, but no objection from me.

-- 
Joel