[llvm-dev] Level of support for ARM LLD

[Mark Kettenis via llvm-dev]

> Date: Thu, 26 Jul 2018 18:29:33 +0100
> From: Peter Smith via llvm-dev <llvm-dev at lists.llvm.org>
> 
> 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.

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
===================================================================
RCS file: /cvs/src/gnu/llvm/tools/lld/ELF/Config.h,v
retrieving revision 1.5
diff -u -p -r1.5 Config.h
--- ELF/Config.h	6 Apr 2018 14:38:28 -0000	1.5
+++ ELF/Config.h	26 Jul 2018 18:16:58 -0000
@@ -105,6 +105,7 @@ struct Configuration {
   std::vector<uint8_t> BuildIdVector;
   bool AllowMultipleDefinition;
   bool AndroidPackDynRelocs = false;
+  bool ARMHardFPAbi = false;
   bool ARMHasBlx = false;
   bool ARMHasMovtMovw = false;
   bool ARMJ1J2BranchEncoding = false;
Index: ELF/InputFiles.cpp
===================================================================
RCS file: /cvs/src/gnu/llvm/tools/lld/ELF/InputFiles.cpp,v
retrieving revision 1.1.1.4
diff -u -p -r1.1.1.4 InputFiles.cpp
--- ELF/InputFiles.cpp	6 Apr 2018 14:26:36 -0000	1.1.1.4
+++ ELF/InputFiles.cpp	26 Jul 2018 18:16:58 -0000
@@ -477,6 +477,9 @@ static void updateSupportedARMFeatures(c
       Config->ARMHasMovtMovw = true;
     break;
   }
+  auto VFPArgs = Attributes.getAttributeValue(ARMBuildAttrs::ABI_VFP_args);
+  if (VFPArgs == ARMBuildAttrs::HardFPAAPCS)
+    Config->ARMHardFPAbi = true;
 }
 
 template <class ELFT>
Index: ELF/Arch/ARM.cpp
===================================================================
RCS file: /cvs/src/gnu/llvm/tools/lld/ELF/Arch/ARM.cpp,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 ARM.cpp
--- ELF/Arch/ARM.cpp	6 Apr 2018 14:26:37 -0000	1.1.1.2
+++ ELF/Arch/ARM.cpp	26 Jul 2018 18:16:58 -0000
@@ -100,7 +100,7 @@ uint32_t ARM::calcEFlags() const {
   // We don't currently use any features incompatible with EF_ARM_EABI_VER5,
   // but we don't have any firm guarantees of conformance. Linux AArch64
   // kernels (as of 2016) require an EABI version to be set.
-  return EF_ARM_EABI_VER5;
+  return EF_ARM_EABI_VER5 | (Config->ARMHardFPAbi ? EF_ARM_VFP_FLOAT : 0);
 }
 
 RelExpr ARM::getRelExpr(RelType Type, const Symbol &S,