Level of support for ARM LLD

Hi,
Could someone please connect me to the POC for ARM support on LLD

Thanks

Not sure there is an official POC, you are probably better off asking
whatever question you have directly on the list.

Cheers,
Rafael

Sumonto Ghosh via llvm-dev <llvm-dev@lists.llvm.org> writes:

Thanks Rafael, wondering as of what is the level of support for ARM and is it close to production quality?

Thanks

I think ARM ELF is pretty good. I was able to link clang with it some
time ago and it now has support for thunks.

Cheers,
Rafael

Sumonto Ghosh <sumonto.ghosh@gmail.com> writes:

Is there a regression bot with a list of tests or alike

Thanks

Hello Sumonto,

There are several upstream build bots that run the Arm specific LLD
tests. You can find these tests in the lld/test/ELF directory, they
all start with arm. At Linaro we are planning to set up a build-bot,
modelled on the equivalent AArch64 one that does a 2 stage build of
clang with LLD as the linker, this will also include running the test
suite.

For the ELF port; the major Arm specific features that it is missing are:
- Full support for BuildAttributes.
- Big Endian support.
- Support for older Architectures such as Arm v4, v5 and v6.
- Errata fixes supported by ld.bfd such as the cortex-a8.

I do have some plans to improve support for BuildAttributes as these
are important for embedded systems. I've got some downstream patches
for v5 and v6 support (limit branch range, and use different
instructions in stubs), however I don't think anyone has actually
needed support yet. Big endian support is a little trickier than for
other architectures as the linker needs to endian reverse all the
instructions. There isn't much use of Big Endian on Arm outside of
networking though so getting access to hardware to test on is
difficult. I'm not planning on adding the errata fixes as these are
quite disruptive and the affected CPUs are now quite old and not in
wide use.

Peter

I've got some downstream patches
for v5 and v6 support (limit branch range, and use different
instructions in stubs), however I don't think anyone has actually
needed support yet.

For FreeBSD we're on a path to having Clang + lld as our toolchain for
all Tier-1 architectures. Tier 2 and 3 architectures may rely on an
external toolchain (Clang- or GCC-based) installed from a package or
from the ports collection. I'd like to have v6 as Tier 1, in part to
support the (original) Raspberry Pi.

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.

Big endian support is a little trickier than for
other architectures as the linker needs to endian reverse all the
instructions. There isn't much use of Big Endian on Arm outside of
networking though so getting access to hardware to test on is
difficult.

We do have BE Arm support in FreeBSD, but as with your comment I do
not think it is widely used, and I would not be bothered if it remains
a Tier 2 architecture in FreeBSD.

In short, for FreeBSD I hope to see v6 be well-supported by lld. If v5
and BE support arrives in lld we'll use it, but from my perspective
it's a rather low priority.

In the Chromium project we switched to lld for linking the Android port of the browser about a month ago. As with all ports of the browser, the Android port is continuously tested, and we are already shipping an lld-linked browser on the dev and canary channels.

Peter

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.

We do have BE Arm support in FreeBSD, but as with your comment I do
not think it is widely used, and I would not be bothered if it remains
a Tier 2 architecture in FreeBSD.

After the original message was sent BE Arm support has been removed
from FreeBSD.

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

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

Date: Thu, 26 Jul 2018 18:29:33 +0100
From: Peter Smith via llvm-dev <llvm-dev@lists.llvm.org>

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

Funny this comes up today as I've just made OpenBSD/armv7 use lld as
the default linker.

Diff below (against the OpenBSD tree, so essentially LLVM 6.0.0)
implements the requested functionality. The flag is set based on the
build attributes in .ARM.attributes. It gets set as soon as a single
object that uses the VFP calling standard is seen.

Index: ELF/Config.h

Thanks for the background - I've made the change in FreeBSD's ELF
header now https://svnweb.freebsd.org/changeset/base/336745

Thanks for posting the patch. I'll hopefully have something early next
week. I'm likely to go in a slightly different direction as there are
some edge cases surrounding combinations of objects with conflicting
Tag_ABI_VFP_args that I haven't quite worked out the best way of
handling yet.

Peter