From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Cc: binutils@sourceware.org, gdb@sourceware.org
Subject: Re: Support for alpha-osf, mips-irix
Date: Sun, 12 Jul 2020 03:08:20 +0100 (BST) [thread overview]
Message-ID: <alpine.LFD.2.21.2007120239190.3508753@eddie.linux-mips.org> (raw)
In-Reply-To: <yddy2nsg459.fsf@CeBiTec.Uni-Bielefeld.DE>
On Thu, 9 Jul 2020, Rainer Orth wrote:
> Every once in a while I come across references to Tru64 UNIX
> (alpha*-dec-osf*) and SGI IRIX in the binutils-gdb tree. This seems
> strange given that the last versions supported by GCC (Tru64 UNIX V5.1
> and IRIX 6.5) were obsoleted in GCC 4.7 back in 2012 and removed in GCC
> 4.8. GDB took a bit longer, but GDB 7.9 removed support for both as
> well in 2015, although a few references have been overlooked.
>
> Both platforms are long obsolete and I strongly suspect there's no one
> to benefit from continued support (whatever that means) in binutils alone.
>
> Any objections to removing support completely? I'm not yet certain how
> either or both is entangled with code for other targets still supported
> (alpha-linux, mips-linux).
Technically we could delete the IRIX configuration triplets, but that
does not buy us much as they use ELF (a peculiar variation of, e.g. the
sort order of the symbol table is different from generic ELF), so painful
extraction of dead pieces of ELF support code would be required, and then
parts of IRIX 5 ELF format support, which the IRIX 6 ELF format has some
further differences from, are used by some embedded MIPS targets, so parts
of that code would have to stay. Not worth the effort IMO.
Then IRIX test results look so-so mostly due to the ELF peculiarity
causing output not to match regexps, but overall there's nothing wrong
there AFAIK, just the missing manpower to clean the tests up (I did some
of that work back when MIPS target maintenance was a part of my dayjob).
Similar failures happen for the affected embedded targets, although
they're limited to tests that do not require shared library support.
> There's even more prehistoric cruft, btw., e.g. references to
> mips-ultrix ;-)
That (ECOFF) has been deleted AFAIK, except for minimal BFD support to
keep `objcopy' to/from ELF working, to satisfy the requirement of some
bootloaders fixed in the firmware. Of course the removal of the remaining
pieces made code verification a tad problematic (perhaps we could have a
binutils/ test that runs `objcopy' both ways and checks basic consistency
though).
Maciej
next prev parent reply other threads:[~2020-07-12 2:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-09 14:21 Rainer Orth
2020-07-12 2:08 ` Maciej W. Rozycki [this message]
2020-07-13 10:49 ` Alan Modra
2020-07-13 11:11 ` Rainer Orth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.21.2007120239190.3508753@eddie.linux-mips.org \
--to=macro@linux-mips.org \
--cc=binutils@sourceware.org \
--cc=gdb@sourceware.org \
--cc=ro@CeBiTec.Uni-Bielefeld.DE \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).