This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] Introduce "target_gdbarch" variable
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 18 Aug 2008 15:33:23 +0400
- Subject: Re: [rfc] Introduce "target_gdbarch" variable
- References: <200808131952.m7DJqVoN009120@d12av02.megacenter.de.ibm.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