llvm dev - Jul 2018 - Level of support for ARM LLD

On 26 July 2018 at 15:52, Ed Maste <emaste at freebsd.org>
wrote:
> On 27 February 2018 at 09:06, Ed Maste <emaste at freebsd.org> wrote:
>>
>> A number of companies are shipping products based on FreeBSD/arm, on
>> v5 and up. As far as I know those using older processors are also
>> using older versions of FreeBSD (with a toolchain based on GCC and
>> Binutils). I suspect that they'll use more recent processors and a
>> contemporary FreeBSD version for new designs.
>
> We currently have one known open issue blocking our use of lld as the
> system linker for FreeBSD/armv7: LLVM PR 36009. Output binaries do not
> have the EF_ARM_VFP_FLOAT flag set. Our rtld uses the flag to choose
> the appropriate library path.
>
I can take a look at that for you. Please feel free to CC me on the PR
if there are any LLD Arm or AArch64 problems as I may not see the PR.

Just to check; is EF_ARM_VFP_FLOAT the same as EF_ARM_ABI_FLOAT_HARD
(0x00000400).

The ABI for the Arm architecture doesn't define EF_ARM_VFP_FLOAT, but
it does define EF_ARM_ABI_FLOAT_HARD and EF_ARM_ABI_FLOAT_SOFT.
See page 17 of
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf

Peter

On 26 July 2018 at 11:08, Peter Smith <peter.smith at linaro.org>
wrote:
> On 26 July 2018 at 15:52, Ed Maste <emaste at freebsd.org> wrote:
>> On 27 February 2018 at 09:06, Ed Maste <emaste at freebsd.org>
wrote:
>>>
>>> A number of companies are shipping products based on FreeBSD/arm,
on
>>> v5 and up. As far as I know those using older processors are also
>>> using older versions of FreeBSD (with a toolchain based on GCC and
>>> Binutils). I suspect that they'll use more recent processors
and a
>>> contemporary FreeBSD version for new designs.
>>
>> We currently have one known open issue blocking our use of lld as the
>> system linker for FreeBSD/armv7: LLVM PR 36009. Output binaries do not
>> have the EF_ARM_VFP_FLOAT flag set. Our rtld uses the flag to choose
>> the appropriate library path.
>
> I can take a look at that for you. Please feel free to CC me on the PR
> if there are any LLD Arm or AArch64 problems as I may not see the PR.
Ok, I've CC'd you on that one. It's the only open PR I'm aware
of at
the moment; if we submit PRs to track movt/movw and other pre-v7
issues I'll add you on them too.
> Just to check; is EF_ARM_VFP_FLOAT the same as EF_ARM_ABI_FLOAT_HARD
> (0x00000400).
Yes, we have:
#define EF_ARM_SOFT_FLOAT 0x00000200
#define EF_ARM_VFP_FLOAT 0x00000400

I see this same constant in Linux (arch/arm/include/asm/elf.h),
introduced in
https://github.com/torvalds/linux/commit/8ec53663d2698076468b3e1edc4e1b418bd54de3

If this is just a Linux mistake in the name (that we somehow
inherited) we can change it to

#define EF_ARM_ABI_FLOAT_HARD 0x00000400
#define EF_ARM_VFP_FLOAT EF_ARM_ABI_FLOAT_HARD

On 26 July 2018 at 18:05, Ed Maste <emaste at freebsd.org>
wrote:
> On 26 July 2018 at 11:08, Peter Smith <peter.smith at linaro.org>
wrote:
>> On 26 July 2018 at 15:52, Ed Maste <emaste at freebsd.org> wrote:
>>> On 27 February 2018 at 09:06, Ed Maste <emaste at
freebsd.org> wrote:
>>>>
>>>> A number of companies are shipping products based on
FreeBSD/arm, on
>>>> v5 and up. As far as I know those using older processors are
also
>>>> using older versions of FreeBSD (with a toolchain based on GCC
and
>>>> Binutils). I suspect that they'll use more recent
processors and a
>>>> contemporary FreeBSD version for new designs.
>>>
>>> We currently have one known open issue blocking our use of lld as
the
>>> system linker for FreeBSD/armv7: LLVM PR 36009. Output binaries do
not
>>> have the EF_ARM_VFP_FLOAT flag set. Our rtld uses the flag to
choose
>>> the appropriate library path.
>>
>> I can take a look at that for you. Please feel free to CC me on the PR
>> if there are any LLD Arm or AArch64 problems as I may not see the PR.
>
> Ok, I've CC'd you on that one. It's the only open PR I'm
aware of at
> the moment; if we submit PRs to track movt/movw and other pre-v7
> issues I'll add you on them too.
>
>> Just to check; is EF_ARM_VFP_FLOAT the same as EF_ARM_ABI_FLOAT_HARD
>> (0x00000400).
>
> Yes, we have:
> #define EF_ARM_SOFT_FLOAT 0x00000200
> #define EF_ARM_VFP_FLOAT 0x00000400
>
> I see this same constant in Linux (arch/arm/include/asm/elf.h),
> introduced in
https://github.com/torvalds/linux/commit/8ec53663d2698076468b3e1edc4e1b418bd54de3
>
> If this is just a Linux mistake in the name (that we somehow
> inherited) we can change it to
>
> #define EF_ARM_ABI_FLOAT_HARD 0x00000400
> #define EF_ARM_VFP_FLOAT EF_ARM_ABI_FLOAT_HARD
Digging a little bit more, it seems like EF_ARM_SOFT_FLOAT and
EF_ARM_VFP_FLOAT were used by the GNU tools when the ABI version was
unknown. The ABI decided to define the official names for Version 5 in
a compatible way. To quote from the document I linked earlier:
EF_ARM_ABI_FLOAT_HARD (0x00000400) (ABI version 5 and later)
Compatible with legacy (pre version 5) gcc use as EF_ARM_VFP_FLOAT.
EF_ARM_ABI_FLOAT_SOFT (0x00000200) (ABI version 5 and later)
Compatible with legacy (pre version 5) gcc use as EF_ARM_SOFT_FLOAT.

I guess I'll have to think about what the best thing to do here is. My
initial thought is that it is best to use the documented ABI names in
source code as they'll be easier to look up. When the name is visible
to humans (readelf etc.) we should use EF_ARM_ABI_FLOAT_HARD if the
ABI version is 5 and EF_ARM_VFP_FLOAT otherwise.

Peter