This is the mail archive of the
mailing list for the glibc project.
RE: [RFC v2] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Maciej Rozycki <Maciej dot Rozycki at imgtec dot com>, Joseph Myers <joseph at codesourcery dot com>
- Cc: "linux-mips at linux-mips dot org" <linux-mips at linux-mips dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "binutils at sourceware dot org" <binutils at sourceware dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 11 Nov 2016 10:23:36 +0000
- Subject: RE: [RFC v2] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.firstname.lastname@example.org> <6D39441BF12EF246A7ABCE6654B023537E40C27F@hhmail02.hh.imgtec.org> <alpine.DEB.email@example.com>
Maciej Rozycki <Maciej.Rozycki@imgtec.com> writes:
> I'm back to this effort now, thanks for patience.
Likewise, this thread got buried in email. At the risk of further delaying
this work I do still have issues with the design.
> > > 3.4 Relocatable Object Generation
> > >
> > > Tools that produce relocatable objects such as the assembler shall
> > > always produce a SHT_MIPS_ABIFLAGS section according to the IEEE Std
> > > 754 compliance mode selected. In the absence of any explicit user
> > > instructions the `strict' mode shall be assumed. No new `legacy'
> > > objects shall be produced.
> > Is it necessary to say that no new legacy objects can be created?
> It is of course not necessary in the sense that we are free to make a
> decision here rather than being constrained by hardware or another
> technical requirement.
> However I think only supporting the two explicit `strict' and `relaxed'
> modes makes the solution proposed consistent, and has indeed been the
> basis of my design.
This is the bit I think is actually less consistent than it seems on the
surface. The issue is that we have to punch holes in the design in order
to facilitate those users who don't care about ieee compliance and the
way it is done currently is that we allow the static linker to completely
override the 'strict'ness of an input object when using --ieee=relaxed.
This means that a user consciously creating an object that 'needs' ieee
compliance via use of -fieee=strict or -mieee=strict is thwarted by the
next user who builds the executable. This kind of scenario can occur with
a static library prepared by an expert in floating point and then someone
casually including that into a bigger application. Obviously a similar
issue is present with the rules around executable and shared libraries
where the executable's compliance mode can override a shared library
but at this level we are not losing any information and the executable
has either very specifically been set to 'relaxed' mode or the kernel
has set legacy to mean relaxed. The latter can at least be fixed by
changing the kernel. Losing information in a static link cannot be
The assumption in the specification is that a user creating a final
executable is the one who should know about ieee compliance issues but
I am not convinced about this. I think it is at the compilation unit
level that issues of ieee compliance should be decided and that should
be a conscious act of the user (or toolchain packager if they want to
force all software to care). I.e. a strict object is strict without
exception throughout static linkage.
The point about not removing legacy objects is that it is an ideal
container for individual objects that don't care or don't yet know
they care about ieee compliance.
The relaxed variant then only becomes applicable when linking multiple
objects and a user has specifically asked to downgrade legacy to relaxed.
Given a legacy object could already be downgraded to relaxed under the
current spec then this does not affect the behaviour of a legacy object.
What this also means is that we can propagate 'legacy' objects through
relocatable links to still get a legacy object which is consistent with
respect to its nan encoding and only later at final link downgrade,
upgrade or retain the compliance level.
These rules combined also mean that a new toolchain that includes
support for these features will, by default, just continue to behave
as today which is the norm for new features. If a user or toolchain
packager decides to enforce stricter ieee checks then they can and
they can face the complexities of combining old and new software
packages as laid out in this spec.
The static linker rules would be almost the same as now but would
not allow strict to be downgraded to relaxed and the 'default' behaviour
could result in legacy objects if they were the only ones in the link.
The spec is currently a little vague on default linker behaviour when
no --ieee option is given but the rules for combining objects without
an override seem relatively obvious. Any 'relaxed' object leads to
a relaxed executable, any 'strict' object leads to a strict executable,
'strict' and 'relaxed' cannot mix, otherwise 'legacy'. This also
eliminates the need for 'nowarn/warn'.
> The principle I have followed here has been that it's the author of
> software who knows exactly what his code requires for correct operation,
> and sets the correct flags in the Makefile or whatever build system he
> uses. Joseph's earlier proposal to have a generic `-fieee' option
> rather than a target one fits here very well in that the author can
> stick it in the build system without the exact knowledge of what target-
> specific constraints may be. Such an option would preferably be placed
> such that it is not accidentally lost e.g. with an OS distribution
> packager's CFLAGS override, which is typically made in a system-wide
> automated way when a distribution is build.
> Still a distribution packager or another person building their piece of
> software of interest, perhaps individually, has control here, being able
> to change build options one way or another, at least by patching
> Makefiles if necessary. So they can choose `strict' or `relaxed' as
Agreed but this is a per object issue not per executable hence the
> Finally the system administrator configuring a system or the individual
> user running software has the least knowledge of the low-level
> requirements of individual pieces of software.
As above I believe this includes the person building an executable as
> So ideally we'd not even have these kernel override modes and
> unconditionally treat `legacy' binaries as `strict', under the principle
> of the least surprise. Realistically however that would make the
> transition to R5/R6 very painful for people, requiring them to rebuild
> all software previously built for the legacy NaN encoding, even though
> only a small subset of software actually relies on the semantics of
> signalling NaNs.
> And this is exactly where the idea of a user-selectable kernel
> acceptance mode came from. I expect that both existing and new
> installations on legacy-NaN hardware will continue operating with the
> `strict' conformance mode and won't ever have to switch that as any new
> software built for
> pre-R5 targets and with the 2008-NaN encoding in mind will be built as
> `relaxed' binaries. Whereas virtually all R5/R6 installations will run
> in the `relaxed' conformance mode, permitting the use of any existing
> pre-R5 `legacy' binaries, however with the risk of some of them
> producing the wrong results.
I have no objections to any of the kernel level support. I think it safely
covers all the requirements.
> Consequently allowing new tools to build more `legacy' binaries will
> just let the issue continue where the mode software being run in depends
> on the hardware configuration rather than a conscious choice of the
> software packager. Whereas support for running `legacy' binaries in the
> mode is really there to help people transition.
We don't need to make this choice for users though. They can make it
for themselves. It is not end users that will make the initial decision
anyway it is distribution maintainers. If those distro maintainers don't
care then we should not remove the tools to do what they want.
> > I think there is value in still being able to generate legacy objects
> > because of the fact that strict executables leave no room for override
> at runtime.
> > Apart from the fact that strict cannot be disabled there is otherwise
> > no difference between legacy and strict compliance modes.
> Can you please be more specific? Where's the value from letting people
> override the mode of software known to require signalling NaN support?
As above the spec actually permits overriding software known to require
signalling NaN support currently which is the basis of my concerns. This
is the linker level --ieee=relaxed option which I expect would end up the
default in any general purpose distro.
Ref: section 3.3.2 third paragraph.
> > I believe the strict option is really intended for conscious use so
> > that programmers who know they need it, can use it. Ordinary users
> > still get the casual safety they need as legacy objects are just as
> > good as strict until overridden. If we lose the ability to override
> > then in some environments we will accumulate lots of needlessly strict
> > executables just because of a tools upgrade whereas the old tools
> > would have generated executables that were as safe but also could be
> overridden by kernel options.
> I think the casual safety is an illusion.
> As soon as a user gets an execution error from a legacy-NaN legacy
> binary on 2008-NaN hardware (or vice versa), they'll hit Google or
> discussion list archives for a solution, find the `ieee754=relaxed'
> kernel option, stick it into their bootloader configuration and forget
> about it, running all their software from the on in the `relaxed' mode
> Eventually distributions will probably do that as well even if they
> built their own packages as `relaxed', to reduce support noise from
> people running `legacy' third-party software built for the opposite NaN
> Now, assuming that their software is indeed safe for `relaxed' mode
> operation with the binary `strict'/`relaxed' choice available you have
> valuable information carried within binaries themselves -- they tell you
> whether they care about signalling NaN interpretation or not rather than
I think you took my comments to suggest I didn't agree with having strict
binaries at all. Quite the opposite, the new 'strict' mode is essential
similarly for relaxed albeit I don't find relaxed quite as important it
plays a part.
> > Allowing legacy objects to be generated may also allow the linkage
> > rules to be tightened. I.e. Forcing a relaxed mode at link time could
> > simply fail if confronted by a strict object instead only allowing
> > legacy objects to be relaxed.
> We can still have a mode where a `strict' object is rejected in a
> static link. Though I'm not sure if there's value in it. If so, then
> perhaps we need a `never relax' flag instead. Do you have a specific
> use case in mind?
I think I've covered this above. I do not believe we need to complicate
this any further to achieve the goals as legacy objects already have
a suitable definition to handle the case of
> > A default build of GCC and binutils would therefore still generate
> > legacy objects until someone consciously updated the configure options
> > or used command line options.
> As I've argued above I'm inconvinced that keeping the `legacy' mode
> supported for newly built binaries is a good idea. If you're concerned
> about software being built as `strict' unnecessarily, then I think we
> have two solutions here:
No that is not my concern. My concern is that at static link time we
can disregard the strict flag.
> 1. We can default the toolchain configuration to the `relaxed' (or
> strictly speaking the `relaxed-exec') mode. This way someone
> their OS from sources will not fall into a trap of building their
> software as `strict' by the lone result of missing the required
> newly-added configuration option, rather than a conscious decision.
> think this would be a reasonably safe move, as a signalling NaN
> requirement is I believe relatively uncommon across software.
Regardless of the detail of the spec I am absolutely certain that the
default options used for tools in debian and fedora will mean all
executables turn out as relaxed (or legacy) i.e. all compatible with both
HW nan encodings. It would actually be safer if the binaries came out
as legacy like today then relaxed because at least then we would still
know they have a consistent nan encoding and it is only the kernel that
is involved in deciding if they should be accepted on incompatible HW
or not. If we get relaxed by default then nobody can control whether they
are accepted on incompatible hardware.
> 2. An idea has been proposed to have objects marked by the assembler to
> indicate whether they include an FP hardware instruction or not. The
> latters would automatically become don't-cares as far as NaN encoding
> is concerned and if all the objects were such in a given static link,
> then the resulting executable would become NaN-encoding agnostic,
> ignoring any `strict' or `relaxed' modes. This would exclude a large
> amount of software from the checks discussed in this specification,
> although a question still remains open how shared libraries loaded by
> such a program would be treated if they for a change did include FP
> hardware instructions.
Definitely need to work on attributing modules that truly don't care about
floating point but this issue does not reduce/increase my concerns about
the spec for the ieee compliance features.
> Does either of the proposals address your concerns? Is there anything I
> may have missed here?
Sorry for all the proposed changes but I think we have got more complexity
than necessary so need to work through these issues more.