Re: ARM EABI v3

[Richard Earnshaw <rearnsha at arm dot com>]

On Tue, 2004-03-23 at 16:40, Daniel Jacobowitz wrote:
> On Tue, Mar 23, 2004 at 04:33:24PM +0000, Paul Brook wrote:
> > The patch below adds basic binutils support for AAELF (EABI v3).
> 
> I'm curious...
> 
> > !     unsigned int flags = meabi_flags;
> >   
> > !     switch (meabi_flags)
> >         {
> > !       case EF_ARM_EABI_UNKNOWN:
> > ! 	/* Set the flags in the private structure.  */
> > ! 	if (uses_apcs_26)      flags |= F_APCS26;
> > ! 	if (support_interwork) flags |= F_INTERWORK;
> 
> ...
> 
> > +       case EF_ARM_EABI_VER3:
> > + 	/* No additional flags to set.  */
> > + 	break;
> 
> Is implementing the v3 EABI flag useful when it causes us to lose all
> supplementary information about the object file, e.g. interworking, FP
> format, etc?  I assume the plan is to record at least some of this
> information in the future, but this patch lets -meabi=3 produce
> "compatible" object files that really can't be usefully linked
> together.

The ARM EABI is about binary compatibility between multiple compilers
amongst other things.  Part of that binary compatibility requires that
the version field of the flags header is set correctly.

In addition to that the existing attributes mechanism is horribly broken
(not to mention wasteful of a rather valuable resource).  For example,
it can't distinguish between hard-float, soft-float and no float at all
(many flags are often marked incorrectly in object files) and it can't
tell you about several sub-architecture variations.  I'm not sure yet
what the best replacement is, but it will certainly not be by using the
flags field in the header.

A more powerful system would have the attributes created by the compiler
and encoded in the assembly source.  Most attributes should be at least
three-way: set, clear and absent.  Objects with an attribute absent are
always compatible with both set and clear.

R.