[PATCH 5/7] MIPS testsuite cleanup - part 5 (irix related)

Maciej W. Rozycki macro@codesourcery.com
Mon Sep 8 22:34:00 GMT 2014


On Mon, 8 Sep 2014, Matthew Fortune wrote:

> > > This patch fixes issue solely shown by irix configurations. I'm
> > > not convinced there is any value in continuing to have irix
> > > support in binutils given it is end of life. I'll follow up with
> > > an RFC to look at deprecation and removal of this. The same
> > > goes for non-traditional output and emulations for MIPS although
> > > I suspect that may be met with slightly more resistance.
> > 
> > Yeah, IRIX can definitely go.  I wanted to do that myself but it's
> > such a tangled web that in the end I wasn't sure it was worth
> > physically removing the code.

 FWIW that's been my perception too, the differences between IRIX and 
traditional formats aren't that big and code that has to tell them apart 
is only sparsely present across our sources, so the effort IMO would be 
for a questionable gain.  Plus some of that stuff would have to stay for 
legacy bare-iron targets anyway, e.g. plain `mips-elf'; I suspect there's 
enough such code in the field.

> That sounds promising then. I'll do an RFC to allow anyone else to
> comment in case anyone has some obsession with irix.

 I think here it is the wrong place to ask -- you do not want to know 
whether binutils developers want to use the tools for a given target (IRIX 
in this case), you want to know whether there are such users out there, 
and if they are willing to support maintenance if so.  I believe our usual 
way of making users aware of an impending target support removal has been 
to make at least one release (though I'd feel more comfortable if there 
were two -- not everyone rushes upgrading) with the relevant (IRIX here)
configuration triplets marked as deprecated so that the end users have a 
chance to notice that in the configuration process and take action if they 
wish.  Then if no objections have been seen until after the second 
release, support can be finally physically removed.

 I think any vendor's EOL status of any configuration is not really that 
relevant, people can be on self support (were source licences available 
for IRIX?).  What matters is whether there's someone interested in using 
and maintaining a given configuration.

> > "Non-traditional" output has been the norm for plain mips*-elf
> > (as opposed to MTI-vendor mips*-elf) for a long time though.
> > I think there would need to be a compelling reason to change.
> 
> I can't say I understand all the differences between the two output
> formats but would like to. It occurs to me that the differences
> may not be especially important for bare metal builds but were for
> irix vs linux/bsd.

 The main differences are I believe a different symbol table sorting 
algorithm (most notably the distinction between what symbols are 
considered local and what are external) and the presence of special 
SHN_MIPS_TEXT, etc. section references.

 Please note that the `abi=O32' vs `no abi set' ELF annotation is not 
really IRIX vs traditional, binutils used to do that universally long ago 
and I still have old Linux binaries I had no need to recompile that bear 
no ABI annotation (i.e. default to o32 as it used to be interpreted).  
We'll probably have to support it indefinitely to allow linking old object 
code (assuming the semantics that was the standard back then; most notably 
traditional SVR4 o32 FPU model), the sources to which may not be available 
to people.

> > If this patch isn't used by anything other than IRIX, let's drop it.
> > The IRIX results have been terrible for a long time and there is no
> > benefit in weakening the test just for IRIX.
> 
> I was hoping you may say that which is why the patches are separate.

 If bad test suite results were the lone reason to discard IRIX support, 
then I could probably find some time to polish them, without weakening the 
affected tests for other targets.  I already did some of such cleaning up 
in the past -- it's usually not difficult, just boring.

  Maciej



More information about the Binutils mailing list