Subject: VFP/soft-float indicators in object files
To: None <firstname.lastname@example.org>
From: Jason R Thorpe <email@example.com>
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... ]
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
* 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
-- Jason R. Thorpe <firstname.lastname@example.org>