This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] [2/6] Replace DEPRECATED_FUNCTION_START_OFFSET
- From: Eli Zaretskii <eliz at gnu dot org>
- To: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- Cc: deuling at de dot ibm dot com, gdb-patches at sourceware dot org
- Date: Tue, 19 Jun 2007 08:43:27 +0300
- Subject: Re: [rfc] [2/6] Replace DEPRECATED_FUNCTION_START_OFFSET
- References: <200706182038.l5IKcoQI005277@d12av02.megacenter.de.ibm.com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Mon, 18 Jun 2007 22:38:50 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> 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.