If all goes well, I plan on pulling the trigger to switch armv6 to hard float API from its current hard float with soft-float API it's using. If you are running armv4 or armv5 hardware, then you are unaffected. If you are running arm64 / aarch64, you are unaffected. You're unaffected if you are on any other architecture.
A couple of Anticipated FAQs:
Q: Where can I find this so I can test it?
It's currently in review. https://reviews.freebsd.org/D5550 is what I plan to commit if all goes well April 2nd.
Q: What about the upgrade path?
The plan is that people that need to upgrade their system in place can do so, but they will have to build compat libraries. This is part of buildworld / installworld when WITH_LIBSOFT is set to y. Changes made to ld.so a long time ago will know if you are executing a hardfloat ABI or softfloat ABI binary (which uses hard float instructions). When you run a hard float binary after the change, it will grab the libraries from the default locations in the tree. When you run a soft float binary, it will grab the libraries from /libsoft /usr/libsoft. The same kernel can run both flavors of binaries.
Q: So how do I generate the compat libraries?
You can do this with a buildworld / installworld with WITH_LIBSOFT=y. You can do this with any tree newer than svn revision r296779. There's no need to wait until the cut-over, but building WITH_LIBSOFT until then just generates two identical copies of all the libraries, one installed in /usr/lib and the other in /usr/libsoft.
Q: So I want to use gcc with the new ABI, can I?
The in-tree ABI doesn't support the proper code generation for the hard float ABI. While the command line arguments were added from the newer versions of GCC, the code generation was not. You therefore cannot use the in-tree compiler with the new armv6. gcc 4.5 and newer should support the proper code generator. The tree hasn't been extensively tested with versions of gcc older than about 5.0, however. You'll need to use the external toolchain support and the gcc5 port to explore this option.
Q: What about packages?
pkg(8) will notice that you've upgraded ABIs and will refresh all packages from the repo.
Q: But there's no packages at the moment, what gives?
Yes, part of the reason to give 3 weeks notice is to allow time for these packages to be built, as well as give a chance for wider testing before the trigger is pulled.
Q: What will happen to the armv6hf TARGET_ARCH?
It will go away. Since the default armv6 target now uses that ABI, there's no need for a new one. Since this was never released, we don't have to worry about it. If we wanted the best performance, we'd have to have moved to a new name. But the new name would cause more problems than moving to the new ABI with the old ABI supported through proper shims. It made little sense to obsolete / deprecate armv6 and move to armv6hf in FreeBSD 11. We'd likely have needed two sets of packages, there'd be longer make universe times, etc for the whole life of FreeBSD 11. So we're only going to have one, and it will be the higher performing hard float ABI.
It turns out there's almost no performance gain for most things (though floating point intensive applications benefit marginally). There's a much bigger gain from generating code for your particular ARM core. Much work has been done to make this work (it didn't before, due to a number of bugs that have been fixed).
This change has been discussed and socialized since last summer. Most of the main arm developers are on board (though there is one notable exception) with this transition plan. This has been reported in quarterly reports, as well as disclosed on arm@ a few times over the past year. I had hoped to be sending this message with a July 1st, 2015 cut-over date, but time got away from me a bit.
Since armv6hf has never been in a release, there's no need to carry it forward as a compatibility ABI.
Q: But what if I need to build a system with soft float ABI under 11?
You can still do that. CPUTYPE=soft has been created for this scenario, as well as to generate libraries for WITH_LIBSOFT. It's anticipated that this will live for the entire FreeBSD 11 branch, but go away in FreeBSD 12.
Q: What about compat10 binaries for ARM?
Those won't be provided in any flavor. While arm has reached Tier 1 status in FreeBSD 11, it was not Tier 1 status in FreeBSD 10, so there's no need to generate them as part of project. It's anticipated the demand for these will be quite light.
Q: What if I want to run a hard float ABI system, but still use soft-float packages for a while?
This isn't supported, and little testing has been done here. You may be able to move the shared libraries in the libsoft LD_LIBRARY_PATH and/or just keep the default paths in the libsoft loads. However, this is an untenable situation once you upgrade one of the binaries. In fact, they will all be upgraded by pkg(8) the first time it runs and notices /bin/sh has a different ABI.
Q: Is there a wiki for this change?
You've found it.