Re: [AArch64] Define LP64 BE linker name.

[Richard Earnshaw <rearnsha at arm dot com>]

On 09/01/14 09:50, Richard Earnshaw wrote:
> 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

For clarity, by location here, I mean dirname+basename.

R.

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