Recent removal of a.out and COFF support for sparc

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Recent removal of a.out and COFF support for sparc

John Paul Adrian Glaubitz
Hello!

binutils/bfd recently removed a.out and COFF support for sparc [1].

Unfortunately, this means that we are no longer able to built GRUB
or SILO for sparc/sparc64 which need to be built as a.out binaries
as the Open Boot Firmware requires them to be in a.out format [2].

I would therefore like to ask to start a discussion about a potential
reversal of this commit as I don't think we can forgo being able
to build a bootloader on sparc/sparc64.

Also, since m68k is still very actively maintained (there is even
LLVM support in the works now) and since AmigaOS uses COFF, I would
to ask for the a.out and COFF support for m68k to be reinstated
as well [3].

Thanks,
Adrian

> [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=c9098af41e3246586a30f4f0bdb0ee4367e9a5e7
> [2] https://docs.oracle.com/cd/E19457-01/801-7042/801-7042.pdf
> [3] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=dc12032bca08554cf0a72d224e44f755f7789ff3

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Reply | Threaded
Open this post in threaded view
|

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

Gunther Nikl-2
John Paul Adrian Glaubitz <[hidden email]> wrote:
> I would therefore like to ask to start a discussion about a potential
> reversal of this commit as I don't think we can forgo being able to
> build a bootloader on sparc/sparc64.

> Also, since m68k is still very actively maintained (there is even
> LLVM support in the works now) and since AmigaOS uses COFF, I would
> to ask for the a.out and COFF support for m68k to be reinstated
> as well [3].

COFF was used by AMIX but this system is dead for a very long time.
I take it with AmigaOS you refer to AmigaOS/m68k? FYI, the native object
code and executable format of AmigaOS/m68k is HUNK. However, the GCC
port for AmigaOS used and still uses a.out objects. Initially because
then only the linker had to modified to output HUNK executables.
Today the binutils port for AmigaOS has support to create HUNK objects
with gas, but this requires the m68k-amigaoshunk target triplet. The
AmigaOS BFD backend has linker support to use a.out and/or HUNK objects
as input files to create HUNK executables.
FWIW, there is no support for AmigaOS in the official FSF repositories
for binutils and GCC.

Regards,
Gunther
Reply | Threaded
Open this post in threaded view
|

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

Vladimir 'φ-coder/phcoder' Serbinenko
In reply to this post by John Paul Adrian Glaubitz
I can change code to do conversion to coff ourselves.

вт, 7 авг. 2018 г., 12:56 John Paul Adrian Glaubitz <
[hidden email]>:

> Hello!
>
> binutils/bfd recently removed a.out and COFF support for sparc [1].
>
> Unfortunately, this means that we are no longer able to built GRUB
> or SILO for sparc/sparc64 which need to be built as a.out binaries
> as the Open Boot Firmware requires them to be in a.out format [2].
>
> I would therefore like to ask to start a discussion about a potential
> reversal of this commit as I don't think we can forgo being able
> to build a bootloader on sparc/sparc64.
>
> Also, since m68k is still very actively maintained (there is even
> LLVM support in the works now) and since AmigaOS uses COFF, I would
> to ask for the a.out and COFF support for m68k to be reinstated
> as well [3].
>
> Thanks,
> Adrian
>
> > [1]
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=c9098af41e3246586a30f4f0bdb0ee4367e9a5e7
> > [2] https://docs.oracle.com/cd/E19457-01/801-7042/801-7042.pdf
> > [3]
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=dc12032bca08554cf0a72d224e44f755f7789ff3
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - [hidden email]
> `. `'   Freie Universitaet Berlin - [hidden email]
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
> _______________________________________________
> Grub-devel mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
Reply | Threaded
Open this post in threaded view
|

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

John Paul Adrian Glaubitz
On 08/07/2018 05:04 PM, Vladimir 'phcoder' Serbinenko wrote:
> I can change code to do conversion to coff ourselves.
Shouldn't that be a.out?

And we would still have the problem that other binaries for OBP
can no longer be generated using binutils.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Reply | Threaded
Open this post in threaded view
|

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

John Paul Adrian Glaubitz
In reply to this post by John Paul Adrian Glaubitz
On 08/07/2018 12:51 PM, John Paul Adrian Glaubitz wrote:
> binutils/bfd recently removed a.out and COFF support for sparc [1].
I just noticed that COFF/a.out support for MIPS was removed as well
and shortly after restored since it seems that GRUB also needs
COFF/a.out support on MIPS.

So, can we have COFF/a.out support back, at least for sparc*?

Thanks,
Adrian

> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=8e415ce8fee234cd86f29d8f4ebbbdf0f9c0b031

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Reply | Threaded
Open this post in threaded view
|

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

Alan Modra-3
On Tue, Aug 07, 2018 at 05:56:58PM +0200, John Paul Adrian Glaubitz wrote:
> On 08/07/2018 12:51 PM, John Paul Adrian Glaubitz wrote:
> > binutils/bfd recently removed a.out and COFF support for sparc [1].
> I just noticed that COFF/a.out support for MIPS was removed as well
> and shortly after restored since it seems that GRUB also needs
> COFF/a.out support on MIPS.
>
> 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?

--
Alan Modra
Australia Development Lab, IBM
Reply | Threaded
Open this post in threaded view
|

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

John Paul Adrian Glaubitz
On 08/08/2018 03:55 AM, Alan Modra wrote:
>> 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..

Yes, but that doesn't change the fact that people are still using
it. OpenBoot firmware requires the binary to be in a.out format and
we're therefore stuck with that. It's not that we can change the
hardware in retrospect.

Also, while AOUT and COFF might be old in general, it does not mean
that these formats completely vanish. There are still places where they
are used, see for example Microsoft's PE binaries. And users might still
want to be able to analyze binaries from various sources without
having to dig out a specific version of binutils first.

> The sparc target obsolescence happened here:
> https://sourceware.org/ml/binutils/2016-09/msg00184.html

Well, that question was asked on the binutils mailing list and I think
it's a bit unfair to expect all downstreams to follow all upstream mailing
lists. There is a plethora of very important upstream projects like the
Linux kernel, binutils, gcc, systemd, OpenJDK, gdb and so on and so
forth and trying to keep track of what all of these upstreams are doing
is nearly impossible.

> You've had quite a bit of warning, but I guess you just built binutils
> with --enable-obsolete, or stayed with older binutils.

Again, I think this is an unfair statement. It's simply not possible for
downstreams to track all upstream projects.

On the other hand, why does bfd even need to be reworked so much? Isn't
the idea that people are eventually moving to elfutils or Gold anyway?

> Well, older
> binutils are likely to be better for AOUT anyway.  So what's to
> prevent you using older binutils for sparc-aout?

Distributions usually don't allow multiple versions of the same package
to be part of the same distribution.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Reply | Threaded
Open this post in threaded view
|

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

Maciej W. Rozycki
In reply to this post by Alan Modra-3
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
Reply | Threaded
Open this post in threaded view
|

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

Alan Modra-3
In reply to this post by John Paul Adrian Glaubitz
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.

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.

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.

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!

--
Alan Modra
Australia Development Lab, IBM
Reply | Threaded
Open this post in threaded view
|

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

Alan Modra-3
In reply to this post by Maciej W. Rozycki
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
Reply | Threaded
Open this post in threaded view
|

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

John Paul Adrian Glaubitz
In reply to this post by Alan Modra-3
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 - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Reply | Threaded
Open this post in threaded view
|

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

Joel Brobecker
> > 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.

Not every user has to step up, but someone has to step up. Someone
has to take care of the code, and using the fair-unfair approach,
it would not be fair to ask existing maintainers to maintain a target
they are not interested in either.

--
Joel
Reply | Threaded
Open this post in threaded view
|

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

Phil Blundell-3
In reply to this post by John Paul Adrian Glaubitz
On Wed, 2018-08-08 at 15:45 +0200, John Paul Adrian Glaubitz wrote:
> 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?

Is there any particular reason that those people wishing to build
bootloaders for machines whose PROMs only understand a.out can't simply
use an old version of binutils to do so?  Or, if the requirement is
simply to take an ELF image and transform it into an a.out image that
the PROM can ingest, they could simply write a small tool of their own
to do the required conversion as a post-processing step.  If I
understand correctly they don't need even the full capabilities of
"objcopy", let alone the rest of the binutils, to solve the problem at
hand.

p.
Reply | Threaded
Open this post in threaded view
|

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

John Paul Adrian Glaubitz
In reply to this post by Joel Brobecker
On 08/08/2018 03:54 PM, Joel Brobecker wrote:
>> Again, this isn't fair. You cannot expect having to step up as a maintainer
>> just because they are users of some code.
>
> Not every user has to step up, but someone has to step up. Someone
> has to take care of the code, and using the fair-unfair approach,
> it would not be fair to ask existing maintainers to maintain a target
> they are not interested in either.

Again, I understand the problem, it's not the first time I am having
such a discussion. There was a similar one regarding POWER5 support
in Golang [1] and the SPE backend in gcc [2].

The problem is just that we are talking about code here that people
are actively using so I'm not sure what the alternatives are.

Adrian

> [1] https://github.com/golang/go/issues/19074
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Reply | Threaded
Open this post in threaded view
|

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

Joel Brobecker
> Again, I understand the problem, it's not the first time I am having
> such a discussion. There was a similar one regarding POWER5 support
> in Golang [1] and the SPE backend in gcc [2].
>
> The problem is just that we are talking about code here that people
> are actively using so I'm not sure what the alternatives are.

I only see two alternatives:

  1. Someone has enough interest to step up and maintain the code;
  2. Use an older version of binutils.

I think option (2) is a good option. It might mean that your host
system doesn't have that option out of the box, but you can still
build an older version of binutils separately. We do this all
the time so as to avoid depending on the host distribution to
determine what version of binutils we use.

--
Joel
Reply | Threaded
Open this post in threaded view
|

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

Cary Coutant-3
In reply to this post by John Paul Adrian Glaubitz
>> 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?

Why isn't *what* done on gold? Gold is ELF-only and doesn't use BFD.

-cary
Reply | Threaded
Open this post in threaded view
|

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

John Paul Adrian Glaubitz
On 08/08/2018 04:39 PM, Cary Coutant wrote:

>>> 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?
>
> Why isn't *what* done on gold? Gold is ELF-only and doesn't use BFD.

Development of new features. I know that Gold is ELF-only that's why
I was wondering why BFD isn't just kept in maintenance mode.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Reply | Threaded
Open this post in threaded view
|

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

Michael Matz
In reply to this post by John Paul Adrian Glaubitz
Hi,

On Tue, 7 Aug 2018, John Paul Adrian Glaubitz wrote:

> binutils/bfd recently removed a.out and COFF support for sparc [1].
>
> Unfortunately, this means that we are no longer able to built GRUB or
> SILO for sparc/sparc64 which need to be built as a.out binaries as the
> Open Boot Firmware requires them to be in a.out format [2].

Link as ELF and use elftoaout to convert to a.out.


Ciao,
Michael.
Reply | Threaded
Open this post in threaded view
|

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

Richard Earnshaw (lists)
In reply to this post by Joel Brobecker
On 08/08/18 15:20, Joel Brobecker wrote:

>> Again, I understand the problem, it's not the first time I am having
>> such a discussion. There was a similar one regarding POWER5 support
>> in Golang [1] and the SPE backend in gcc [2].
>>
>> The problem is just that we are talking about code here that people
>> are actively using so I'm not sure what the alternatives are.
>
> I only see two alternatives:
>
>   1. Someone has enough interest to step up and maintain the code;
>   2. Use an older version of binutils.
>

3. Use a post-link conversion tool to generate an a.out image from the
ELF binary.

> I think option (2) is a good option. It might mean that your host
> system doesn't have that option out of the box, but you can still
> build an older version of binutils separately. We do this all
> the time so as to avoid depending on the host distribution to
> determine what version of binutils we use.
>

Reply | Threaded
Open this post in threaded view
|

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

Cary Coutant-3
In reply to this post by John Paul Adrian Glaubitz
>> Why isn't *what* done on gold? Gold is ELF-only and doesn't use BFD.
>
> Development of new features. I know that Gold is ELF-only that's why
> I was wondering why BFD isn't just kept in maintenance mode.

Gold supports only a small fraction of the platforms that BFD does,
and many of those platforms don't use ELF. In addition, almost all of
the other binutils tools use BFD. BFD is far from being relegated to
maintenance mode.

-cary
12