Re: [AArch64] Define LP64 BE linker name.

[Richard Earnshaw <rearnsha at arm dot com>]

On 08/01/14 18:27, David Daney wrote:
> On 01/08/2014 01:24 AM, Richard Earnshaw wrote:
>> 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.
> 
> Yes, I fully understand that.  That is why we are concerned about this.
> 
> 
>>   /lib/ld-linux-aarch64.so.1 is already used for LE, so BE needs a
>> different name.
>>
> 
> Yes that is an indisputable fact.
> 
> The question is:  Should the discrimination be done in the "basename" 
> portion of the path or the "dirname" portion?
> 

Basename was the consensus choice of the *linux distros* when we had a
conference call about this for the ARM soft/hard-float kernel loaders.
It seems to me that exactly the same arguments apply to AArch64 and
big/little LP64/ILP32 situations.

The problem was that none of the distros were prepared to accept the
other's directory layouts (and didn't want to have directories
containing exactly one file).  All of them were, however, prepared to
accept the basename being different and the file living in /lib.

> 
>>> 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 terms of library names and locations, BE vs. LE is no different than 
> any of the other incompatible ABI variants.  We have used multi-lib 
> configurations for these in the past, why not for BE vs. LE?
> 
>>>
>>> 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.
> 
> Yes, Debian separates the ABI specific files into different directory trees.
> 
> Look at what RedHat does for x86_64:  We have /lib and /lib64.
> 
> On MIPS we have either the new Debian Way, or /lib, /lib32, and /lib64.
> 
> I will restate my question:  Why do you want to combine ABI specific 
> files for incompatible ABIs into a single directory?  What are the 
> advantages of doing that over separating them as has historically been done?
> 
>>
>>> 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.
> 
> Yes.  It is special, that is why we need to have a good reason for not 
> using state-of-the-art multi-lib techniques for handling it.
> 
> When you build a full distribution with a gazillion packages, you will 
> have a much easier time of things if all those packages will not be 
> clobbering libraries from alternate ABIs.  Separating the ABI specific 
> libraries into their own directory hierarchies is how we handle this. 
> So I think it makes more sense to place the dynamic linker into the the 
> root of such a hierarchy (as is done for many other architectures) 
> rather than make up a bunch of unique names in /lib.
> 

If you can convince the distros that there is a better way of doing
this, and they can *all agree on what that method is*, then I'm quite
happy to reconsider; but from the debate I listened to last time around
I doubt you will succeed and I don't do a distro so don't need
convincing on this issue.

All I require is that there is one location for the loader on all
distros.  I don't want to see this become a per-distro choice as the
answer really is baked into the binaries and varying it would break any
chance of cross-distro binary compatibility.

R.

> 
>>
>>> 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.
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
>