This is the mail archive of the
mailing list for the binutils project.
RE: [PATCH 5/7] MIPS testsuite cleanup - part 5 (irix related)
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: Richard Sandiford <rdsandiford at googlemail dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 8 Sep 2014 23:33:52 +0100
- Subject: RE: [PATCH 5/7] MIPS testsuite cleanup - part 5 (irix related)
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B0235320F05745 at LEMAIL01 dot le dot imgtec dot org> <87bnqtythl dot fsf at googlemail dot com> <6D39441BF12EF246A7ABCE6654B0235320F0683C at LEMAIL01 dot le dot imgtec dot org>
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
> > 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.