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: Jim Blandy <jimb at codesourcery dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: "Ulrich Weigand" <uweigand at de dot ibm dot com>, deuling at de dot ibm dot com, gdb-patches at sourceware dot org
- Date: Tue, 19 Jun 2007 11:57:11 -0700
- Subject: Re: [rfc] [2/6] Replace DEPRECATED_FUNCTION_START_OFFSET
- References: <200706182038.l5IKcoQI005277@d12av02.megacenter.de.ibm.com> <utzt4qz28.fsf@gnu.org>
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.