armv8 removed the coprocessor instructions other than cp14, so on an armv8 system the related hwcaps should never be set. new llvm complains about the use of coprocessor instructions in armv8-a mode (even though they are never executed at runtime), so ifdef them out when musl is built for armv8.
this is a subtle issue with how the assembler/linker work. for the adr pseudo-instruction used to find __hwcap, the assembler in thumb mode generates a 16-bit thumb add instruction which can only represent word-aligned addresses, despite not knowing the alignment of the label. if the setjmp function is assigned a non-multiple-of-4 address at link time, the load then loads from the wrong address (the last instruction rather than the data containing the offset) and ends up reading nonsense instead of the value of __hwcap. this in turn causes the checks for floating-point/vector register sets (e.g. IWMMX) to evaluate incorrectly, crashing when setjmp/longjmp try to save/restore those registers. fix based on bug report by Felix Hädicke.
sp cannot be used in the ldm/stm register set in thumb mode.
these files are all accepted as legacy arm syntax when producing arm code, but legacy syntax cannot be used for producing thumb2 with access to the full ISA. even after switching to UAL, some asm source files contain instructions which are not valid in thumb mode, so these will need to be addressed separately.
the idea of the three-instruction sequence being removed was to be able to return to thumb code when used on armv4t+ from a thumb caller, but also to be able to run on armv4 without the bx instruction available (in which case the low bit of lr would always be 0). however, without compiler support for generating such a sequence from C code, which does not exist and which there is unlikely to be interest in implementing, there is little point in having it in the asm, and it would likely be easier to add pre-armv4t support via enhanced linker handling of R_ARM_V4BX than at the compiler level. removing this code simplifies adding support for building libc in thumb2-only form (for cortex-m).
the code to save/restore vfp registers needs to build even when the configured target does not have fpu; this is because code using vfp fpu (but with the standard soft-float EABI) may call a libc built for a soft-float only, and the EABI considers these registers call-saved when they exist. thus, extra directives are used to force the assembler to allow vfp instructions and to avoid marking the resulting object files as requiring vfp. moving away from using hard-coded opcode words is necessary in order to eventually support producing thumb2-only output for cortex-m. conditional execution of these instructions based on hwcap flags was already implemented. when building for arm (non-thumb) output, the only currently-supported configuration, this commit does not change the code emitted.
the issue is identical to the recent commit fixing the mips versions: despite other implementations doing this, it conflicts with the requirements of ISO C and it's a waste of time and code size.
not heavily tested, but at least they don't seem to break anything on soft float targets with or without coprocessors. they check the auxv AT_HWCAP flags to determine which coprocessor, if any, is available.