Target triplets

[Adhemerval Zanella]

On 11/01/2019 10:40, Adhemerval Zanella wrote:
> 
> 
> On 11/01/2019 09:59, Christer Solskogen wrote:
>> On 11.01.2019 12:13, Florian Weimer wrote:
>>
>>> I'm not aware of anyone building a distribution, but I don't follow
>>> (32-bit) Arm developments.
>>>
>>
>> I was thinking more in the direction that it is not mentioned in the README file. binutils support it, but not gcc.
> 
> The arm-linux-gnu is usually referenced as 'old' arm ABI and it differs
> on some points from new embedded ABI. AFAIK the main points are:
> 
>   1. OABI assumes underlying machine supports floating point support.
>      It means that if the hardware does not have floating-point support
>      (quite common on old ARM chips), an exception will be generated and 
>      the kernel will emulate the instruction (incurring in a context switch 
>      into the kernel).
> 
>      On Linux it is defined by CONFIG_FPE_NWFPE and it will add the code
>      on arch/arm/nwfpe.
> 
>   2. The kernel interface is also different in some ways, which makes
>      some syscalls incompatibles. First difference is eabi says 64-bit
>      members should be 64-bit aligned instead of simply word aligned. 
>      EABI also pads structures to the size of the largest member it 
>      contains instead of the invariant 32-bit [1].
> 
>      It means that Linux need to provide this extra syscalls and
>      handle it accordingly. This is defined by OABI_COMPAT.
> 
>   3. The syscall itself it done slight differently which complicates
>      the libc code. OABI requires that system call number be encoded 
>      into the swi/svc instruction, where EABI requires the system call 
>      number to be on r7. For OABI this requires the kernel to actually
>      fetch the instruction word and analyse to decode which syscall to
>      issue.
> 
> [1] As described as arch/arm/kernel/sys_oabi-compat.c
> 

Also to give some more context, the OABI support was removed around 2011-2012
on libc-ports [1] [2] [3]. As you can see, it required a lot of specialized 
code and my understanding the rationale is ARM ecosystem was moving away
from OABI and there is no sense to continue support it on glibc.

[1] https://sourceware.org/ml/libc-ports/2012-01/msg00023.html
[2] https://sourceware.org/ml/libc-ports/2012-04/msg00122.html
[3] https://sourceware.org/ml/libc-ports/2012-04/msg00123.html