Re: [rfc] Introduce "target_gdbarch" variable

["Ulrich Weigand" <uweigand@de.ibm.com>]

Joel Brobecker wrote:

> Just my 2 cents...

Thanks for looking at this!

> > The idea is that this variable would stay even as other uses of
> > current_gdbarch are being eliminated in favor of per-thread etc.
> > architectures.
> 
> I am wondering why these ones are OK to stay, or perhaps you were
> thinking of a short-to-medium term situation. Otherwise, isn't this
> global going to be a problem with true multi-arch? Another situation
> where this might be a problem is when the debugger is debugging more
> than one process from different architectures (Stan's project).

The idea was that target_gdbarch is the architecture assoicated with
the connection to one target.  As we currently support only one target
at a time, using a global for that should be fine.  As soon as we start
supporting multiple target connections at the same time, we'd need 
multiple instances of this as well.  At this point, it would probably
make sense to make this a member of "struct target".

> > Does this seem reasonable?
> 
> It seems reasonable to me, modulo the part where I don't understand
> why the current globals used in target-remote/solib are OK to stay.

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

Similarly, "solib" stores the overall method to use to search for
shared libraries as gdbarch properties.  Again, this is a global
property of a certain target, even though the inferior may have
some threads / frames that use a different architecture.

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.

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

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com