This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][aarch64] Fix the big endian loader name
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Marcus Shawcroft <marcus dot shawcroft at gmail dot com>
- Cc: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, Marcus Shawcroft <marcus dot shawcroft at arm dot com>
- Date: Fri, 06 Mar 2015 12:03:40 -0500
- Subject: Re: [PATCH][aarch64] Fix the big endian loader name
- Authentication-results: sourceware.org; auth=none
- References: <54F985F1 dot 5070103 at arm dot com> <54F9D4AB dot 3020003 at redhat dot com> <CAFqB+PxxoywG1o44WaYpkppgCe6OAOyJqjF0TjyNrzn9P7fU=w at mail dot gmail dot com>
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.