On 27 February 2018 at 05:29, Peter Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote:> 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.
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.> 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.
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