Re: armelfp: new architecture name for an armel variant
+++ Paul Brook [2010-07-11 14:16 +0100]:
> > 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.
Right - that's the thing I was thinking it would be helpful to actually
fill in as that makes it possible for the linker to prevent you trying
to run things you can't run (with better error messages than
'instruction abort') or for it to choose alternative variants.
Can we use this feature to mark alternate functions within a binary - e.g. a
'tubby-elf' format version of libm containing both soft-emulation and
VFP versions of functions?), or does it apply to the whole binary?
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: