[llvm-dev] Level of support for ARM LLD

[Peter Smith via llvm-dev]

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

On 26 July 2018 at 19:25, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>> 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,
>