Moving armv6 from soft float to hard

There are several paths forward to move the arm v6 support from soft float to hard. One step has been taken already in the creation of the armv6hf MACHINE_ARCH. However, that's an unsatisfying way forward for many reasons. It solves the problem (getting a way to use hard float), but creates other problems (the upgrade path is tough, scripts must change to recognize the new architecture, etc).

Another path forward would be to simply turn on hardware float. This is easy, but has upgrade issues (think of what happens during buildworld or after a buildworld when someone runs a pre-change binary). This page focuses on those issues, possible solutions to them and fully documenting any issues or workarounds necessary to make things work properly.



Longer explanation


ld not conforming to EABI5 spec

Currently, ld doesn't mark the binaries as soft or hard float, even though it knows. The eflags part of the ehdr in the elf file is 0x50000000 for .o files and 0x50000002 for binaries and shared libraries. This is incorrect. While it was correct for EABI 4, it is incorrect for EABI5. EABI5 files need to have either EF_ARM_VFC_FLOAT or EF_ARM_SOFT_FLOAT flags set. There is wiggle room in the standard for no bits set implying SOFT_FLOAT, but we even set no flags on the hard float binaries we create with experimental armv6hf MACHINE_ARCH. The proper fix is to mark the binaries correctly. ld isn't the proper place to fix .o's, but is the proper place to fix shared libraries and executables. In addition, attributes aren't copied correctly to shared libraries.,, and

clang not conforming to the EABI5 spec

clang should, but doesn't, mark the .o's in similar way to ld

needs patch

Floating point system calls different

There are no system calls that use floating point, it is purely a userland argument passing convention (passing the floats in int regs or floating point regs)

Done. Not an issue.

Enforcing hard vs soft when linking in .so does no sanity checking for library type. Sensible, since on other platforms it isn't needed. and the putative should do the checking.

needs code, structure of makes checks harder

Choosing hard vs soft float at runtime

Need to create augment so it can differentiate between hard and soft float binaries. It should use LD_SOFT_* wherever it uses LD_* environment variables when dealing with a soft float binary. It should look at /usr/libsoft and /libsoft instead of /usr/lib and /lib for binaries (though it should look at the latter two for soft binaries after the new directories for better compatibility and upgradability)


Diagnosing library choice of hard vs soft float at runtime

Need to teach ldd about soft float

Pending review D2493 outcome.

Packages (pkg)

The pkg system groks a number of different ABIs. It will detect that the ABI of the system shifted from the last time it ran and automatically download the new packages. It appears that we can have multiple sets available at the same time, one for the old soft-float ABI, and one for the new.

Should work, need to test.

Soft float libraries

May need a way to generate the soft float libraries the same way we generate the lib32 ones

Cut and paste of the lib32 code started, but a number of subtle differences make this problem harder to solve as many 'issues' for lib32 are papered over by the fact that it is 32 vs 64 bit and ignored by the current system. Not impossible, just challenging.


Not an issue: armv6 not supported in FreeBSD 10, so no need to have upgrades work.

Done. Not an issue.

Building ports

We haven't tried an experimental ports run yet.

Coordinate with Sean Bruno.


Need to use similar logic to the lib32 stuff to build libsoft for maximum compatibility.

Flip the switch

Need to create a switch to allow soft-float somehow, but default to hard float in

Patch needed.

armv6tohardfloat (last edited 2015-07-17T22:53:50+0000 by WarnerLosh)