Re: [rfc] [2/6] Replace DEPRECATED_FUNCTION_START_OFFSET

[Jim Blandy <jimb@codesourcery.com>]

Eli Zaretskii <eliz@gnu.org> writes:
>> 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.

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.