This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]