All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Alan Modra <amodra@gmail.com>
Cc: Nick Clifton <nickc@redhat.com>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	binutils@sourceware.org,
	The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: Recent removal of a.out and COFF support for sparc
Date: Wed, 8 Aug 2018 11:59:22 +0100 (BST)	[thread overview]
Message-ID: <alpine.LFD.2.21.1808081143490.18023@eddie.linux-mips.org> (raw)
In-Reply-To: <20180808015529.GP26457@bubble.grove.modra.org>

Alan,

> > So, can we have COFF/a.out support back, at least for sparc*?
> 
> I would rather remove all AOUT support.  AOUT as a format has been
> obsolete since the advent of ELF in the 1990s.  See for example
> J. Arnold "ELF: An Object File to Mitigate Mischievous Misoneism", In
> Proc. of the Summer USENIX Conference, 1990.
> COFF should have died too..
> 
> The sparc target obsolescence happened here:
> https://sourceware.org/ml/binutils/2016-09/msg00184.html
> 
> You've had quite a bit of warning, but I guess you just built binutils
> with --enable-obsolete, or stayed with older binutils.  Well, older
> binutils are likely to be better for AOUT anyway.  So what's to
> prevent you using older binutils for sparc-aout?

 I don't like things being put that way and I find it against the spirit 
of free software and its mission to deliver superior solutions that do not 
put unnecessary limits upon users.  If people have a need for a feature, 
then I think it is the wrong thing to refuse it from the position of 
authority given that code for that exists.

 However, as usually, we, as a group of people working on binutils, are a 
limited resource and cannot afford taking care of less commonly used 
features we have no use for ourselves.  So I think a fair way of putting 
things would be to offer the resurrection of the feature provided that 
someone steps in and offers to maintain it properly, so that other people, 
and general maintainers in particular, do not have to worry about it.

 I suspect that, just like with MIPS ECOFF support, it will be enough if 
we have BFD support, so that tools like `objcopy' and `objdump' continue 
working, and all the hairy linker infrastructure can go.  But that would 
have to be confirmed by actual users.  Same about GDB if required; I 
believe the same basic BFD support will suffice to support the GDB side.

 FWIW,

  Maciej


  parent reply	other threads:[~2018-08-08 12:07 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-07 10:51 Recent removal of a.out and COFF support for sparc John Paul Adrian Glaubitz
2018-08-07 12:58 ` Gunther Nikl
2018-08-07 15:04 ` Vladimir 'phcoder' Serbinenko
2018-08-07 15:16   ` John Paul Adrian Glaubitz
2018-08-07 15:56 ` John Paul Adrian Glaubitz
2018-08-08  1:55   ` Alan Modra
2018-08-08  9:07     ` John Paul Adrian Glaubitz
2018-08-08 13:16       ` Alan Modra
2018-08-08 13:45         ` John Paul Adrian Glaubitz
2018-08-08 13:54           ` Joel Brobecker
2018-08-08 14:03             ` John Paul Adrian Glaubitz
2018-08-08 14:20               ` Joel Brobecker
2018-08-08 15:15                 ` Richard Earnshaw (lists)
2018-08-08 14:39           ` Cary Coutant
2018-08-08 14:41             ` John Paul Adrian Glaubitz
2018-08-08 17:08               ` Cary Coutant
2018-08-08 18:11                 ` John Paul Adrian Glaubitz
2018-08-08 18:25                   ` Andreas Schwab
2018-08-08 18:27                   ` Maciej W. Rozycki
2018-08-08 18:30                     ` Paul Koning
2018-08-08 21:26                       ` John Paul Adrian Glaubitz
2018-08-08 21:23                     ` John Paul Adrian Glaubitz
2018-08-08 21:27                       ` Paul Koning
2018-08-08 21:35                         ` John Paul Adrian Glaubitz
2018-08-08 21:53                           ` Joel Brobecker
2018-08-09  0:03                           ` Paul Koning
2018-08-09  3:43                             ` Jeff Law
2018-08-08 21:32                       ` Andrew Pinski
2018-08-09 12:34                   ` Michael Matz
2018-08-08 10:59     ` Maciej W. Rozycki [this message]
2018-08-08 13:34       ` Alan Modra
2018-08-08 18:14         ` Maciej W. Rozycki
2018-08-10  9:57           ` Jose E. Marchesi
2018-08-10 10:12             ` John Paul Adrian Glaubitz
2018-08-08 15:07 ` Michael Matz

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.1808081143490.18023@eddie.linux-mips.org \
    --to=macro@linux-mips.org \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=grub-devel@gnu.org \
    --cc=nickc@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.