This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Binutils 2.26 released
- From: Tristan Gingold <gingold at adacore dot com>
- To: Pierre Muller <pierre dot muller at ics-cnrs dot unistra dot fr>
- Cc: binutils <binutils at sourceware dot org>
- Date: Mon, 1 Feb 2016 15:31:22 +0100
- Subject: Re: Binutils 2.26 released
- Authentication-results: sourceware.org; auth=none
- References: <9F317B17-DC7C-42A1-A3BD-89E7A349FAE5 at adacore dot com> <56A8FC25 dot 6060503 at ubuntu dot com> <00cb01d15cf3$e9a8fef0$bcfafcd0$ at muller@ics-cnrs.unistra.fr> <3834D8F4-3992-47FD-9680-089D631A8DD8 at adacore dot com> <00dd01d15cf9$e98d2ad0$bca78070$ at muller@ics-cnrs.unistra.fr>
> On 01 Feb 2016, at 15:07, Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> wrote:
>
> I am willing to submit a patch,
> the problem is that I am not sure I understand the error...
>
> There are many other AT_XXX macros in
> /usr/include/sys/auxv.h
>
> Thus I suppose that gcc does not generate an error
> if the old macro and the new are the same,
> otherwise I would have gotten an error on the first AT_NULL macro.
>
> Thus it is only because in auxv.h there is:
> #define AT_SUN_CAP_HW1 2009
> followed by
> #define AT_SUN_HWCAP AT_SUN_CAP_HW1 /* deprecated; for backward compat */
> whereas in include/elf/common.h
> #define AT_SUN_HWCAP 2009 /* Machine dependent hints about
> processor capabilities. */
>
> So should I restrict the change to AT_SU_HWCAP only,
> or rather discard the whole AT_XXX macros?
I would simply restrict the change to AT_SUN_HWCAP. Add a comment
to explain the reason (Solaris headers define the macro differently
but with the same value).