Hi Maciej, 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@xxxxxxxxxx> 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 be relaxed. 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. Thanks, Matthew
