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: Richard Sandiford <rdsandiford at googlemail dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: Matthew Fortune <Matthew dot Fortune at imgtec dot com>, "binutils\ at sourceware dot org" <binutils at sourceware dot org>
- Date: Tue, 09 Sep 2014 07:18:44 +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> <alpine dot DEB dot 1 dot 10 dot 1409082302260 dot 27075 at tp dot orcam dot me dot uk>
"Maciej W. Rozycki" <email@example.com> writes:
> On Mon, 8 Sep 2014, Matthew Fortune wrote:
>> 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.
The removal of IRIX support from GCC is more relevant here though.
AFAIK there were no objections when Rainer suggested it should be removed,
and GCC is a package that (a) had been actively maintained and tested
on IRIX and (b) gives new features on each upgrade. Rainer did the
testing using the vendor linker IIRC, because GNU ld didn't work. And...
>> > 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.
...that's really my objection to keeping it a supported target.
Getting the testsuite failures down to zero by making the testsuite
match the current output is pointless when there's anecdotal evidence
that the current output doesn't work on the system. We should only
keep it alive if there is someone who's willing to test it on a real
IRIX box. And with GCC support gone, that seems a bit unlikely.
I remember spending a reasonable amount of time getting binutils 2.16
(IIRC) working on IRIX, both gas and ld. I wasn't writing the port,
just fixing problems (usually incompatibilities with GNU/Linux) that had
crept in since the original IRIX work was done. I doubt we've managed
to avoid introducing a new IRIX bug since then, with all the extra
GNU/Linux work we've been doing.
E.g. in this particular case would the idea be to make the testsuite
expect the abiflags section and segment on IRIX? Or should the section
be omitted there? (And so create a very different code path?) There's
a reasonable chance the native tools and dynamic linker will be confused
by this new information. Making the testsuite give zero failures for
one choice is pointless before we know which choice is correct.