Message ID | 54F985F1.5070103@arm.com |
---|---|
State | Committed |
Headers |
Received: (qmail 74311 invoked by alias); 6 Mar 2015 10:49:01 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 74298 invoked by uid 89); 6 Mar 2015 10:49:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, SPF_PASS autolearn=ham version=3.3.2 X-HELO: service87.mimecast.com Message-ID: <54F985F1.5070103@arm.com> Date: Fri, 06 Mar 2015 10:48:17 +0000 From: Szabolcs Nagy <szabolcs.nagy@arm.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: libc-alpha@sourceware.org CC: Marcus Shawcroft <marcus.shawcroft@arm.com> Subject: [PATCH][aarch64] Fix the big endian loader name X-MC-Unique: 115030610482001501 Content-Type: multipart/mixed; boundary="------------060309080107000001000809" |
Commit Message
Szabolcs Nagy
March 6, 2015, 10:48 a.m. UTC
AArch64 uses arch specific configure.ac fragment to set HAVE_AARCH64_BE in config.h so later the loader name can be decided based on this macro. However config.h.in needs an appropriate line to generate the macro. I think the loader name should be managed in a simpler way for future abi variants. Changelog: 2015-03-06 Szabolcs Nagy <szabolcs.nagy@arm.com> * config.h.in (HAVE_AARCH64_BE): Add.
Comments
On 03/06/2015 05:48 AM, Szabolcs Nagy wrote: > AArch64 uses arch specific configure.ac fragment to set HAVE_AARCH64_BE > in config.h so later the loader name can be decided based on this macro. > > However config.h.in needs an appropriate line to generate the macro. > > I think the loader name should be managed in a simpler way for future > abi variants. > > Changelog: > > 2015-03-06 Szabolcs Nagy <szabolcs.nagy@arm.com> > > * config.h.in (HAVE_AARCH64_BE): Add. > Since you are talking about the "long term", what you propose is not what we want. Roland, please correct me if I'm wrong, but I think the consensus was that all machine-dependent macros should move out of the top-level config.h.in, and into the machine directories. Unfortunately that requires work and rejiggering and we just keep putting the machine macros into the top-level config.h.in. Cheers, Carlos.
On 6 March 2015 at 16:24, Carlos O'Donell <carlos@redhat.com> wrote: > On 03/06/2015 05:48 AM, Szabolcs Nagy wrote: >> AArch64 uses arch specific configure.ac fragment to set HAVE_AARCH64_BE >> in config.h so later the loader name can be decided based on this macro. >> >> However config.h.in needs an appropriate line to generate the macro. >> >> I think the loader name should be managed in a simpler way for future >> abi variants. >> >> Changelog: >> >> 2015-03-06 Szabolcs Nagy <szabolcs.nagy@arm.com> >> >> * config.h.in (HAVE_AARCH64_BE): Add. >> > > Since you are talking about the "long term", what you propose is > not what we want. > > Roland, please correct me if I'm wrong, but I think the consensus > was that all machine-dependent macros should move out of the top-level > config.h.in, and into the machine directories. > > Unfortunately that requires work and rejiggering and we just keep > putting the machine macros into the top-level config.h.in. Looks to me that this change is need to make the existing configure.ac work as intended. I would have thought it is better to separate such fixes from restructure work. Cheers /Marcus
On 03/06/2015 11:47 AM, Marcus Shawcroft wrote: > On 6 March 2015 at 16:24, Carlos O'Donell <carlos@redhat.com> wrote: >> On 03/06/2015 05:48 AM, Szabolcs Nagy wrote: >>> AArch64 uses arch specific configure.ac fragment to set HAVE_AARCH64_BE >>> in config.h so later the loader name can be decided based on this macro. >>> >>> However config.h.in needs an appropriate line to generate the macro. >>> >>> I think the loader name should be managed in a simpler way for future >>> abi variants. >>> >>> Changelog: >>> >>> 2015-03-06 Szabolcs Nagy <szabolcs.nagy@arm.com> >>> >>> * config.h.in (HAVE_AARCH64_BE): Add. >>> >> >> Since you are talking about the "long term", what you propose is >> not what we want. >> >> Roland, please correct me if I'm wrong, but I think the consensus >> was that all machine-dependent macros should move out of the top-level >> config.h.in, and into the machine directories. >> >> Unfortunately that requires work and rejiggering and we just keep >> putting the machine macros into the top-level config.h.in. > > Looks to me that this change is need to make the existing configure.ac > work as intended. I would have thought it is better to separate such > fixes from restructure work. It is. Sorry, let me be clear, the patch as posted is fine if it is required for AArch64. I was simply talking about "future" things and explaining how we wish this worked. Cheers, Carlos.
On Fri, 6 Mar 2015, Carlos O'Donell wrote: > Roland, please correct me if I'm wrong, but I think the consensus > was that all machine-dependent macros should move out of the top-level > config.h.in, and into the machine directories. That's bug 14068. (The wiki todo list identifies some other cases where we still need to get architecture-specific cases out of generic files.)
On 6 March 2015 at 10:48, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote: > 2015-03-06 Szabolcs Nagy <szabolcs.nagy@arm.com> > > * config.h.in (HAVE_AARCH64_BE): Add. Committed. /Marcus
diff --git a/config.h.in b/config.h.in index 695ca35..73ddb9c 100644 --- a/config.h.in +++ b/config.h.in @@ -260,4 +260,7 @@ /* The PowerPC64 ELFv2 ABI is being used. */ #undef HAVE_ELFV2_ABI +/* AArch64 big endian ABI */ +#undef HAVE_AARCH64_BE + #endif