Re: armelfp: new architecture name for an armel variant
> The tricky-bit here is that instruction-set extensions (VFP3, thumb2,
> NEON) and instruction set versions (v4, v5, v6a, v7) can also be
> incompatible in the sense that they won't run on hardware without
> those features. But I really think we should try to deal with that by
> correctly decorating ELF headers and making sure that the loaders and
> dpkg 'DTRT' in terms of selecting compatible stuff. Not create an arch
> for every combination.
At the object file level (i.e. static linker) this is already handled by the
EABI object attributes.
At the executable/shared library level (i.e. dynamic linker) the EABI defines
PT_ARM_ARCHEXT for this purpose. This is not currently implemented by either
binutils or glibc.