Re: [rfc] Introduce "target_gdbarch" variable

[Joel Brobecker <brobecker@adacore.com>]

Just my 2 cents...

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

> - Giving these uses a different name makes it more obvious that the
>   remaining uses of current_gdbarch should be eliminated while these
>   can stay.

That's a good reason. In fact, I started with something similar when
I first worked on the project of getting rid of the "current_language"
global (which I haven't forgotten about!)

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

-- 
Joel