This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] ARM Floating point defaults


On Tue, 2004-08-03 at 19:03, Paul Brook wrote:
> It appears that gcc and gas use different defaults for hardware floating point 
> flags. On linux and netbsd targets the default is overridden, so everything 
> is ok.
> 
> On other targets[1] gcc defaults to soft-float fpa, but gas defaults to 
> whatever hardware is supported by the CPU.
> 
> This causes a couple of problems:
> - Objects are marked as hard-float by default.
> - Code compiled for armv5 chips are marked as VFP format float.
> Both of these cause linker errors when objects compiled with default options 
> (eg. libc) are mixed with objects compiled with explicitly specified options.
> 
> Would it be acceptable to change the gas defaults to match those used by gcc?
> 
> At the same time, add a linker option that allows linking of objects with 
> incompatible flags. This would allow the user to override the checks when 
> linking old objects with incorrect flags.
> 
> Paul
> 
> [1] The only other gcc target which doesn't default to soft-float is 
> arm-semi-aof, which doesn't isn't supported by gas.

This is a non-trivial problem.  We need a migration path that will move
the defaults *away* from the FPA word ordering of floating point values,
but at the same time will not cause carnage for existing users who are
just upgrading.  The problem is made doubly difficult by the fact that
gcc and binutils are not released in lock-step, so we can't assume a
particular version of GAS from within GCC.

The current attributes stored in the ELF header are (IMO) just broken:

1) They're incompatible with the EABI
2) They don't accurately reflect the contents of objects (you can mark
the object one way, but then put different data in the object itself and
normally the assembler has no way of verifying this).
3) They can't represent that an object has NO floating point content at
all (and is therefore compatible with soft- and hard-float ABIs).
4) They are describing the wrong thing anyway.  What's really important
is the ABI variant in use, not the particular instructions.

So one option would be to just remove the checking entirely until we can
come up with a more robust solution -- it's then caveat emptor for those
developing with GCC, but that's probably less of a nightmare than having
legitimate objects that the linker spuriously rejects (most real users
of GCC only have one type of target at any one time).

We might have to write some autoconf tests for gcc that check if the
assembler groks -mfpu= and -m{hard,soft}-float (or something like
that).  If it does, then gcc should unconditionally pass the appropriate
flags to the assembler (even if they are the default settings).  That
would only leave the cases where the assembler is invoked directly. 
Again, command line options should be recommended, but there still needs
to be a default.

If we go with a static configuration option for binutils, my inclination
would be to make the default VFP format but with a big NEWS item that
tells users of this change and lets them know how to configure things
back the old way.

R.

NOTE: The only way that the various command line options can materially
affect the output of the assembler is if the .double directive is used
to put a floating point literal directly into an object (when the word
order of the generated value will depend on the FPA/VFP target type). 
In all other cases the only effect of these flags is to set the
appropriate bits in the object header.  GCC never uses .double, and most
users don't either since it's exceedingly rare to hand-write floating
point code on ARM.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]