From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32737 invoked by alias); 19 Jun 2007 18:57:16 -0000 Received: (qmail 32729 invoked by uid 22791); 19 Jun 2007 18:57:16 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 19 Jun 2007 18:57:13 +0000 Received: (qmail 18289 invoked from network); 19 Jun 2007 18:57:11 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 Jun 2007 18:57:11 -0000 To: Eli Zaretskii Cc: "Ulrich Weigand" , deuling@de.ibm.com, gdb-patches@sourceware.org Subject: Re: [rfc] [2/6] Replace DEPRECATED_FUNCTION_START_OFFSET References: <200706182038.l5IKcoQI005277@d12av02.megacenter.de.ibm.com> From: Jim Blandy Date: Tue, 19 Jun 2007 18:57:00 -0000 In-Reply-To: (Eli Zaretskii's message of "Tue, 19 Jun 2007 08:43:27 +0300") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-06/txt/msg00375.txt.bz2 Eli Zaretskii writes: >> Date: Mon, 18 Jun 2007 22:38:50 +0200 (CEST) >> From: "Ulrich Weigand" >> Cc: deuling@de.ibm.com (Markus Deuling), gdb-patches@sourceware.org >> >> The purpose of this patch series is to make the "current_gdbarch" that is >> implicit in those macros *explicit* at the call site, so that we can >> subsequently replace it with the appropriate local "gdbarch" architecture. >> This is all part of supporting multiple architectures at the same time. >> >> Now, for those particular cases where the macro is already deprecated, >> we might alternatively just eliminate its use. However, for this specific >> macro some thought is required how that can be done (if at all). I thought >> it made sense to follow through with eliminating all the gdbarch macros >> now, even the deprecated ones. They actual elimination of the deprecated >> routines can happen later on just the same. > > Sorry, but if this is the only reason, it doesn't make sense to me. I > think if we touch deprecated code, we should not replace it with > another deprecated code. If there's a way to eliminate deprecated > features, let's eliminate them, even if it takes more work. > > That is my opinion; if others don't mind, I won't make a fuss out of > it, but I surely feel like we are doing haphazard job here. My opinion is that the change is fine. Ulrich and Markus have already posted a substantial body of patches working towards making GDB support multiple architectures simultaneously. By all indications, the Cell is a priority at IBM, and multi-arch support would be helpful to Cell debugging, so I believe they will carry through. If they do, that would be a major step forward for GDB. If, in the process of making a valuable change, code with an unrelated problem is left still having that unrelated problem, I think that's fine. If the patch introduced new uses of a deprecated facility, then I would not be comfortable with that.