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


> Date: Tue, 23 Oct 2007 12:19:23 +0200
> From: Markus Deuling <deuling@de.ibm.com>
> CC: gdb-patches@sourceware.org, uweigand@de.ibm.com
> 
> > 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

Well, that just says its purpose is to get rid of current_gdbarch, but
there's no serious discussion of the issue.  So I'm still wondering:
was this discussed, and if so, where can I read it?

> current_gdbarch will disappear somewhen and GDB will work on a per-frame architecture base.

I can understand why this is a Good Thing for ports that can actually
support multiple architectures.  But why is this a good idea for
single-architecture ports?  You are replacing a variable reference
with a function call, which is a slowdown.  That's the downside;
what's the upside, please?

To me, this looks like yet another case of good intentions that could
well lead to undesirable consequences for no good reason.  Like the
decision to link against every possible *read.c binary reader, no
matter whether the port has a need for it, it's an annoyance, both
because it's inelegant to bloat a program for want of generality, and
because it causes some very practical problems (link time, executable
size, long GDB startup time when debugging itself, etc.).  For
example, the DJGPP port of GNU ld was constantly complaining about
overflow in source line table (DJGPP uses COFF for binary files), just
because it linked in useless for DJGPP modules such as elfread.c,
mdebugread.c, mipsread.c, xcoffread.c, etc.  I no longer actively use
DJGPP, but I remember the annoyance to this day.

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

For ports that support only one architecture, this variable can be
computed once and then reused.  What's wrong with storing such values
in a global variable?

> At the end one should be able to build GDB with all (nearly all ?!?) targets enabled

Good God! you don't really mean that, do you?  What kind of bloated
GDB executable will we have when this happens?

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

If we cannot imagine such a scenario, why are we trying to support it?


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