[llvm-dev] Level of support for ARM LLD

Ed Maste via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 26 10:05:14 PDT 2018


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


More information about the llvm-dev mailing list