Re: [rfc] [17/17] Get rid of current_gdbarch in go32-nat.c

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Mon, 22 Oct 2007 08:07:40 +0200
> From: Markus Deuling <deuling@de.ibm.com>
> CC: gdb-patches@sourceware.org, uweigand@de.ibm.com
> 
> > Sorry for asking this so late, but could you please explain the
> > reason(s) why these changes are a good idea, i.e. what potential
> > problem(s) are they trying to solve?  If I tell you that the go32
> > (a.k.a. DJGPP) native build of GDB supports only a single
> > architecture, would those reason(s) still hold?
> > 
> 
> sorry for the late respone. I've been on vacation.
> Please see here: http://sourceware.org/ml/gdb-patches/2007-10/msg00108.html

Thanks for the pointer.  Unfortunately, it does not answer my question
above.  Perhaps the earlier thread (to which it refers without stating
a URL) does, in which case I'd like to read that earlier thread.

> What I'll try to achieve is to get rid of the global variable current_gdbarch to have a real per-frame architecture. 

Yes, but why?  It looks like getting rid of current_gdbarch is needed
to support the situation where multiple architectures are supported in
the same session (or maybe even in the same executable?).  That is why
I asked the second question above: the DJGPP native build of GDB
supports only a single architecture, and will ever support only that
single architecture.  So the question is: is there any particular
reason to get rid of current_gdbarch in go32-nat.c?