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

[Markus Deuling <deuling@de.ibm.com>]

H Eli,

Eli Zaretskii schrieb:
>>
>>> 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?
please see my explanation below.

> 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.
You're right. This is the original posting from august this year:
http://sourceware.org/ml/gdb-patches/2007-08/msg00034.html

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

current_gdbarch will disappear somewhen and GDB will work on a per-frame architecture base. There should
be no need to have some global variables for keeping track of current architecture, etc anymore (which is for my opinion
very fault-prone anyway). 

There is not only an advantage with our "combined binaries" which consist of two different architectures in one binary.
At the end one should be able to build GDB with all (nearly all ?!?) targets enabled and then debug all kinds of supported
binaries without the need to recompile or even restart it. This is a cool feature ;-) Whereas I cannot imagine a scenario
where GDB debugs for example an x86 binary and a PowerPC binary in one session.

Thats the reason to replace current_gdbarch piece by piece by appropriate other methods like get_frame_arch or get_regcache_arch
or (what is still under discussion) via a gdbarch pointer in struct objfiles. 

I'm not familiar with the particularities of DJGPP but I hope I was able to answer your question. 


-- 
Markus Deuling
GNU Toolchain for Linux on Cell BE
deuling@de.ibm.com