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


Hi Guys,

On other targets[1] gcc defaults to soft-float fpa, but gas defaults to whatever hardware is supported by the CPU.

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.

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.

I think that we ought to make it a principle that GCC (for ARM) always tells GAS explicitly what ISA and ABI it has used to produce its assembler output, so that whatever defaults are built in to GAS are ignored.


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).

I would actually agree with this. The tests and warnings about floating point mismatches have caused quite a few bug reports, and to my knowledge have not proved to be that useful at all.


I am however concerned that we do not have a proper scheme for labelling object files so that these warnings could be correctly generated. So I would be much happier if instead of just deleteing these checks we could come up with a replacement for them and start implementing it.

Cheers
  Nick




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