Re: Recent removal of a.out and COFF support for sparc

[Alan Modra]

On Wed, Aug 08, 2018 at 11:59:22AM +0100, Maciej W. Rozycki wrote:
> 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.

I'm grumpy, but the advice about using older binutils for unmaintained
ports is good.  I'm also not against reinstating sparc-aout if
someone maintains it, but doubt there is anyone wanting to do the
work.

"git log bfd/aoutx.h" if you want an illustration of points I make in
my other reply on this thread.

>  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

-- 
Alan Modra
Australia Development Lab, IBM