This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] MIPS: IEEE 754-2008 features support
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: Richard Sandiford <rdsandiford at googlemail dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 17 Jul 2013 15:20:55 +0000
- Subject: Re: [PATCH] MIPS: IEEE 754-2008 features support
- References: <alpine dot DEB dot 1 dot 10 dot 1307151634220 dot 20590 at tp dot orcam dot me dot uk> <87mwpmxp5k dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1307162053370 dot 20590 at tp dot orcam dot me dot uk>
On Wed, 17 Jul 2013, Maciej W. Rozycki wrote:
> > I was a bit surprised that a change to the NaN format requires a change
> > to the dynamic linker, but I suppose that's the consequence of forcing
> > every ELF object to fall on one side of the fence?
>
> Yes, the dynamic linker has to enforce NAN2008 ELF file header flag
> compatibility among the modules loaded. The file name has to change to
> avoid accidentally loading an executable with a pre-NAN2008 dynamic linker
> that wouldn't enforce that requirement.
And, whereas any glibc binaries are definitely built for one or the other
NaN format, and the format affects various of the interfaces to glibc,
none of the interfaces to glibc are affected by the ABS/MAC bits; it's
perfectly possible to have one of glibc and a binary using it built to use
ABS2008 or MAC2008, and the other built for the common subset (longer code
sequences for ABS, avoiding MAC instructions whose semantics change - or,
for that matter, using the soft-float ABI, which obviously is only
affected by the NaN changes). So only the NaN changes affect the
interface to glibc in an inherently incompatible way, and only those
changes require a different dynamic linker name.
--
Joseph S. Myers
joseph@codesourcery.com