From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22983 invoked by alias); 24 Oct 2007 13:38:49 -0000 Received: (qmail 22973 invoked by uid 22791); 24 Oct 2007 13:38:48 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate2.de.ibm.com (HELO mtagate2.de.ibm.com) (195.212.29.151) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 24 Oct 2007 13:38:45 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id l9ODcgKR152218 for ; Wed, 24 Oct 2007 13:38:42 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9ODcgWL2244628 for ; Wed, 24 Oct 2007 15:38:42 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9ODcfeS010230 for ; Wed, 24 Oct 2007 15:38:42 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id l9ODcfqp010227; Wed, 24 Oct 2007 15:38:41 +0200 Message-Id: <200710241338.l9ODcfqp010227@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 24 Oct 2007 15:38:41 +0200 Subject: Re: [rfc] [17/17] Get rid of current_gdbarch in go32-nat.c To: drow@false.org (Daniel Jacobowitz) Date: Wed, 24 Oct 2007 13:39:00 -0000 From: "Ulrich Weigand" Cc: eliz@gnu.org (Eli Zaretskii), deuling@de.ibm.com (Markus Deuling), gdb-patches@sourceware.org In-Reply-To: <20071023211528.GA5996@caradoc.them.org> from "Daniel Jacobowitz" at Oct 23, 2007 05:15:28 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00576.txt.bz2 Daniel Jacobowitz wrote: > On Tue, Oct 23, 2007 at 10:53:03PM +0200, Eli Zaretskii wrote: > > 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? > > Even a single-architecture port may have more than one > current_gdbarch. A gdbarch is fine-grained and e.g. different > executables can lead to different gdbarches. So a GDB for DJGPP which > supported debugging two programs at once might need more than one > "current" gdbarch. > > Also, getting rid of current_gdbarch is hard. If we leave it > in some targets then we have to continue making it work; it'll > creep back in to ports that were trying to get rid of it. I > think having more than one way to do this is not worthwhile. Yes, that's my main concern as well. However, getting back to the specific case of the go32-nat.c changes: - if (regno < gdbarch_fp0_regnum (current_gdbarch)) + if (regno < gdbarch_fp0_regnum (get_regcache_arch (regcache))) I actually agree with Eli that this is probably not the right way; instead the "gdbarch_fp0_regnum (current_gdbarch)" should be replaced by simply I386_ST0_REGNUM -- this is the only value gdbarch_fp0_regnum can ever have on i386 targets. (Of course, this will also get rid of this particular use of current_gdbarch, which is my main concern.) > > Good God! you don't really mean that, do you? What kind of bloated > > GDB executable will we have when this happens? > > FYI, I'd love to ship a single GDB binary that supported multiple > targets. That's practical for our case. I don't know if we would > turn on all targets or just a set list. Actually, I'm just preparing to send out a patch set to do just that :-) The only remaining prerequisites are that the solib patches are applies, and the final remaining TM file tm-frv.h is removed. The patches will provide the --enable-targets= configure option, which will work just the same as this option today works with binutils: you will always get the "main" target (--target ...), and in addition support for all targets listed with --enable-targets= is compiled in. A special case is --enable-targets=all, which will support all targets GDB has. Those extra targets can be remote targets only; only the main target can be the native target (when appropriate). Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com