Creating a Fedora ARM distribution part 1: history

You are right that code which doesn't use the VFPv3 isn't specifically impacted by the VFP passing convention in section 6. But the way the ABI change was done (this isn't Fedora's issue), there was no clear set of standardized magical flags just magically inserted into ELF files to tell us whether an application actually uses FP (as opposed to just targeting the/an ABI that handles it). There is the "eabi" section, e.g.:

# readelf -A /bin/bash
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "7-A"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3-D16
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: SP and DP
Tag_ABI_VFP_args: VFP registers
Tag_DIV_use: Not allowed

This will tell us what we build against but it will not tell us whether any floating point instructions were actually used (whether generated or inline assembly). Fedora is not alone in taking the action of treating this as an incompatible ABI break, and in taking an approach similar to what we have done. There were some other reasons for treating this as an entire bootstrap that will be spelled out explicitly in part 2.

Jon.