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

[John Paul Adrian Glaubitz]

On 08/08/2018 03:16 PM, Alan Modra wrote:
> On Wed, Aug 08, 2018 at 11:07:58AM +0200, John Paul Adrian Glaubitz wrote:
>> On the other hand, why does bfd even need to be reworked so much?
> 
> You'd think that the AOUT and COFF support would be stable by now, and
> that's true enough.  There are two or three problems that waste
> maintainers time though.

It works for the people who use it. I don't think anyone claims the
software is perfect.

> One is that people write fuzzers and take a delight in submitting bug
> reports for this old code.  Those bugs take up time Nick and I would
> rather spend elsewhere.  I suppose we could just close them as "won't
> fix", but they are undeniably bugs, and a bug that crashes a program
> might just be exploitable when some luser runs objdump as root.

I think closing those bugs as WONTFIX would be fair, yes. And I think
you can just make AOUT/COFF support configurable at build time.

> Another is that people report bugs about leaked memory.  Generally
> that's also a "don't care", since none of "ld", "as" or any of the
> binutils run as servers.
> 
> Finally, when anyone wants to make changes to data structures or
> functions used by all the backends, we have to change all this old
> code too.

Why isn't this done on Gold though?

> It's not a matter of reworking the code.  No one wants to work on it
> at all!  At least, judging by the number of people actively
> maintaining most of binutils, that seems to be the case.  Are *you*
> interested in maintaining sparc-aout or sparc-coff?  There are sparc
> bug reports dating back to 2004 that no one has analyzed!

Again, this isn't fair. You cannot expect having to step up as a maintainer
just because they are users of some code.

Isn't the idea that Linux distributions are developed by a community
and everyone takes their part? You are certainly also expecting someone
to keep other software you are using maintained and would probably annoyed
in a similar way if upstream just dropped it and told you to maintain
it yourself, wouldn't it?

What do you suggest on the other hand? Shall we tell them because upstream
binutils has dropped AOUT/COFF support, there won't be any bootloaders
anymore for SPARC machines?

Don't get me wrong, I know maintenance resources are limited and I agree
that's a good thing that unsued code gets removed. What I don't understand
is that upstream maintainers remove code that people are still actively using.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - address@hidden
`. `'   Freie Universitaet Berlin - address@hidden
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913