public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
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

  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).