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>, "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>
- Cc: Joseph Myers <joseph at codesourcery dot com>
- Date: Mon, 16 May 2016 14:21:00 +0000
- Subject: RE: [RFC v2] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 00 dot 1605141043120 dot 6794 at tp dot orcam dot me dot uk>
Thanks for the update. I've read through the whole proposal again and
it looks good. I'd like to discuss legacy objects a bit more though...
Maciej Rozycki <Maciej.Rozycki@imgtec.com> writes:
> 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?
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.
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.
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
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.