[AArch64] Define LP64 BE linker name.

[Richard Earnshaw]

On 07/01/14 19:45, David Daney wrote:
> On 01/07/2014 07:23 AM, Richard Earnshaw wrote:
>> On 06/01/14 17:07, Andrew Pinski wrote:
>>> On Mon, Jan 6, 2014 at 7:25 AM, Marcus Shawcroft
>>> <marcus.shawcroft@arm.com> wrote:
>>>> Hi,
>>>>
>>>> This patch defines the AArch64 LP64 BE linker name in LD.
>>>>
>>>>         * emulparams/aarch64linuxb.sh (ELF_INTERPRETER_NAME): Define.
> [...]
>>>> +ELF_INTERPRETER_NAME=\"/lib/ld-linux-aarch64_be.so.1\"
> 
> Why do you want to mix the LE and BE libraries in the same directory?
> 

Well AArch64 can, at least in theory, support BE and LE processes
running on the same machine (needs kernel support, of course).  That
means the software needs to be able to support having both endiannesses.
 /lib/ld-linux-aarch64.so.1 is already used for LE, so BE needs a
different name.

> Perhaps I missed that part of the discussion.

It's similar to the situation on ARM, where we have the potential for
hard-float and soft-float binaries on the same system.

> 
> In the past we have separated different ABIs into separate directory 
> hierarchies.  Why is that not the appropriate thing to do here.
> 

/lib is difficult; it's the one name that's ambiguous.  Go look at what
debian has been doing to support multi-lib - that's even more aggressive
in concept, with one file system able to support every platform they
support.

> The only reason to change the name of the interpreter is to avoid a 
> conflict if both LE and BE ABIs are present in the same filesystem. 
> What are you going to name libc, libm, libpthread, etc.?
> 
Most of those can be handled through configuration files in /etc.  The
dynamic loader is special in that the path to it is hard-coded into the
binary.

> David Daney
> 
>>>
>>> Again I don't think this should be done as right now, binutils 2.24
>>> and with this patch are different ABIs.
>>
>> So do it now, or do it in three years time when this becomes a major
>> problem for someone.
>>
>> I think the sooner the better with issues like this, unfortunate as that
>> is for early adopters.  I'm sure there must be some compatibility
>> work-arounds you can deploy.
>>
>> R.
>>
>>
>>
> 
>