From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23844 invoked by alias); 23 Oct 2007 20:53:54 -0000 Received: (qmail 23835 invoked by uid 22791); 23 Oct 2007 20:53:54 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (213.8.233.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 23 Oct 2007 20:53:51 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-71-212.inter.net.il [80.230.71.212]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id JEU07458 (AUTH halo1); Tue, 23 Oct 2007 22:52:50 +0200 (IST) Date: Tue, 23 Oct 2007 21:15:00 -0000 Message-Id: From: Eli Zaretskii To: Markus Deuling CC: gdb-patches@sourceware.org, uweigand@de.ibm.com In-reply-to: <471DCAAB.7080603@de.ibm.com> (message from Markus Deuling on Tue, 23 Oct 2007 12:19:23 +0200) Subject: Re: [rfc] [17/17] Get rid of current_gdbarch in go32-nat.c Reply-to: Eli Zaretskii References: <470DE4C1.9070509@de.ibm.com> <471C3E2C.3010509@de.ibm.com> <471DCAAB.7080603@de.ibm.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00552.txt.bz2 > Date: Tue, 23 Oct 2007 12:19:23 +0200 > From: Markus Deuling > 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?