Subject: VFP/soft-float indicators in object files
To: None <port-arm@netbsd.org>
From: Jason R Thorpe <thorpej@wasabisystems.com>
List: port-arm
Date: 11/21/2002 07:44:39
[ This message is being CC'd to the NetBSD 1.6 Release Engineering team
  as a heads-up... ]

Hi folks...

One thing we missed when moving to ELF was the markers in the object
files that indicate VFP floating point format and soft-float.  This
means that our object files, as far as the flags in the ELF header are
concerned, are marked has using "FPA hard-float".

This also has the unfortunate side-effect of generating incorrect code
at the assembler level -- mostly because our assembler was missing support
for VFP floating point.  Last night I checked in code to correct this
problem (in md_atof(), the order of bytes emitted by the assembler was
wrong for little-endian VFP).  However, it is not yet enabled by default,
and this is why...

The BFD library makes checkes against the flags in the ELF header to
verify that two objects are compatible.  This means that it currently
errors out of "FPA vs. VFP" and "hard-float vs. soft-float" do not
match in the two objects.

This is annoying -- because it's a flag-day.

Thankfully, there is no change at the ABI level (other than fixing
the bug of incorrect FP constants being emitted by the assembler).
This means that your shared libraries will continue to work, etc.  But
if you want to compile new programs, you'd need to rebuild the libraries
with the new compiler/assembler so that they have the correct markings.

I'm inclined to go ahead and take the hit of a flag-day.  Here is
why:

	* We can pull all these changes up to the netbsd-1-6 branch
	  rather easily (I have requests pending already for all of
	  the toolchain infrastructure fixes).

	* Once the changes are pulled into the netbsd-1-6 branch, the
	  netbsd-1-6 branch autobuilder will generate fresh netbsd-1-6
	  branch binaries which are properly marked.  1.6.1 would also
	  include the new properly-marked binaries.

	* Someone [volunteers would be appreciated, here :-] could
	  do a bulk pkg-build for ARM 1.6.1.  This would mean binary
	  packages would have the correct markings.

	* People running -current... Well, you're running -current :-)
	  Actually, it's not that bad.  I've already made the transition
	  on my Shark.  It was quite painless.

	* As I said above, all your old binaries and shared libraries
	  will continue to work without any problems.  The only problem
	  comes when you attempt to compile a new program, and it is
	  linked against and old library which does not have the correct
	  markings.

Any thoughts/comments?

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>