Recent removal of a.out and COFF support for sparc

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 - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Gunther Nikl]

John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> 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

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

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

I can change code to do conversion to coff ourselves.

вт, 7 авг. 2018 г., 12:56 John Paul Adrian Glaubitz <
glaubitz@physik.fu-berlin.de>:

> 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 - glaubitz@debian.org
> `. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 2618 bytes --]

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 - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[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 - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Alan Modra]

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

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 - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Maciej W. Rozycki]

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

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

[Alan Modra]

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

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

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 - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

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

[John Paul Adrian Glaubitz]

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 - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

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

[Cary Coutant]

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

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 - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Michael Matz]

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.

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

[Richard Earnshaw (lists)]

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

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

[Cary Coutant]

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

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

[John Paul Adrian Glaubitz]

On 08/08/2018 07:08 PM, Cary Coutant wrote:
>>> 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,

Which of the platforms that are still relevant for commercial applications
are supported by BFD which are not supported by Gold?

As far as I know, Gold support x86*, POWER*, ARM*, s390* and MIPS* which
covers all of the targets that distributions like Fedora, openSUSE and
Debian consider as supported release architectures.

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

What about elfutils for these purposes? I have been told by gcc people
that elfutils was supposed to replace binutils in this regard.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Maciej W. Rozycki]

On Wed, 8 Aug 2018, Alan Modra wrote:

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

 Maybe there isn't, maybe there is, but I think we need to be explicit on 
what the conditions are, because people may not be aware of them.  Then it 
is up to whoever wants the feature to determine if they can do something 
to keep it in master or whether the only feasible solution is sticking to 
an older version.

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

 Exactly why I pointed out the need to have an offer to maintain the code 
as a condition.

  Maciej

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

[Andreas Schwab]

On Aug 08 2018, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

> What about elfutils for these purposes? I have been told by gcc people
> that elfutils was supposed to replace binutils in this regard.

BFD is also used by GAS and GPROF.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Maciej W. Rozycki]

On Wed, 8 Aug 2018, John Paul Adrian Glaubitz wrote:

> > Gold supports only a small fraction of the platforms that BFD does,
> 
> Which of the platforms that are still relevant for commercial applications
> are supported by BFD which are not supported by Gold?
> 
> As far as I know, Gold support x86*, POWER*, ARM*, s390* and MIPS* which
> covers all of the targets that distributions like Fedora, openSUSE and
> Debian consider as supported release architectures.

 We have dozens of bare metal targets which only have support in BFD.  
Some of these architectures happen to have Linux support too, for embedded 
applications.  All the world is not Linux.  And all the world are not 
distributions either.  Freescale S12Z is the most recent addition I 
believe, and has no gold support AFAICT.

  Maciej

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

[Paul Koning]

> On Aug 8, 2018, at 2:27 PM, Maciej W. Rozycki <macro@linux-mips.org> wrote:
> 
> On Wed, 8 Aug 2018, John Paul Adrian Glaubitz wrote:
> 
>>> Gold supports only a small fraction of the platforms that BFD does,
>> 
>> Which of the platforms that are still relevant for commercial applications
>> are supported by BFD which are not supported by Gold?
>> 
>> As far as I know, Gold support x86*, POWER*, ARM*, s390* and MIPS* which
>> covers all of the targets that distributions like Fedora, openSUSE and
>> Debian consider as supported release architectures.
> 
> We have dozens of bare metal targets which only have support in BFD.  
> Some of these architectures happen to have Linux support too, for embedded 
> applications.  All the world is not Linux. 

Indeed.  For example, NetBSD support 57 platforms (not quite that many architectures, but a lot more than Linux).

	paul

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

[John Paul Adrian Glaubitz]

On 08/08/2018 08:27 PM, Maciej W. Rozycki wrote:
> On Wed, 8 Aug 2018, John Paul Adrian Glaubitz wrote:
> 
>>> Gold supports only a small fraction of the platforms that BFD does,
>>
>> Which of the platforms that are still relevant for commercial applications
>> are supported by BFD which are not supported by Gold?
>>
>> As far as I know, Gold support x86*, POWER*, ARM*, s390* and MIPS* which
>> covers all of the targets that distributions like Fedora, openSUSE and
>> Debian consider as supported release architectures.
> 
>  We have dozens of bare metal targets which only have support in BFD.

Which is my whole point. If you remove all these targets from BFD, what
would be the point of still using it over Gold or LLVM's LLD?

It's the same argument I see with gcc. One of it's huge selling points
is the plethora of targets it supports. If you go ahead now and cut
out all targets except for the current mainstream targets, you are
removing one huge advantage that gcc has over LLVM.

> Some of these architectures happen to have Linux support too, for embedded 
> applications.  All the world is not Linux.  And all the world are not 
> distributions either.  Freescale S12Z is the most recent addition I 
> believe, and has no gold support AFAICT.

Yep. And that's why I think it's better to keep BFD useful for various
targets and not bother about potential vulnerabilities which don't really
pose a threat in the real world, e.g. the threat that someone is sending
a user a manipulated object file and asking them to open it with "readelf"
or "objcopy" running as root.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[John Paul Adrian Glaubitz]

On 08/08/2018 08:30 PM, Paul Koning wrote:
>> We have dozens of bare metal targets which only have support in BFD.  
>> Some of these architectures happen to have Linux support too, for embedded 
>> applications.  All the world is not Linux. 
> 
> Indeed.  For example, NetBSD support 57 platforms (not quite that many architectures, but a lot more than Linux).

Not really. Linux supports about 25 unique architectures multiplied by various sub-
architectures. You are counting sub-architectures as individual targets in NetBSD.
You are already counting four or five different m68k targets which are covered by a
single m68k target on Linux.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Paul Koning]

> On Aug 8, 2018, at 5:23 PM, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> 
> On 08/08/2018 08:27 PM, Maciej W. Rozycki wrote:
>> On Wed, 8 Aug 2018, John Paul Adrian Glaubitz wrote:
>> 
>>>> Gold supports only a small fraction of the platforms that BFD does,
>>> 
>>> Which of the platforms that are still relevant for commercial applications
>>> are supported by BFD which are not supported by Gold?
>>> 
>>> As far as I know, Gold support x86*, POWER*, ARM*, s390* and MIPS* which
>>> covers all of the targets that distributions like Fedora, openSUSE and
>>> Debian consider as supported release architectures.
>> 
>> We have dozens of bare metal targets which only have support in BFD.
> 
> Which is my whole point. If you remove all these targets from BFD, what
> would be the point of still using it over Gold or LLVM's LLD?
> 
> It's the same argument I see with gcc. One of it's huge selling points
> is the plethora of targets it supports. If you go ahead now and cut
> out all targets except for the current mainstream targets, you are
> removing one huge advantage that gcc has over LLVM.

I don't quite understand.

The original discussion seemed to be the removal of the a.out and coff output options specifically for sparc.  In other words, a target which used to support ELF along with some other formats now supports ELF only.

There are also targets that do not support ELF.  And I know of no plans to remove those targets, or to remove the a.out support they rely on.  I'm maintainer for one of them.  Nor are there plans to trim the target set of gcc down to "current mainstream targets", whatever that might mean.

	paul

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

[Andrew Pinski]

On Wed, Aug 8, 2018 at 2:23 PM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
>
> On 08/08/2018 08:27 PM, Maciej W. Rozycki wrote:
> > On Wed, 8 Aug 2018, John Paul Adrian Glaubitz wrote:
> >
> >>> Gold supports only a small fraction of the platforms that BFD does,
> >>
> >> Which of the platforms that are still relevant for commercial applications
> >> are supported by BFD which are not supported by Gold?
> >>
> >> As far as I know, Gold support x86*, POWER*, ARM*, s390* and MIPS* which
> >> covers all of the targets that distributions like Fedora, openSUSE and
> >> Debian consider as supported release architectures.
> >
> >  We have dozens of bare metal targets which only have support in BFD.
>
> Which is my whole point. If you remove all these targets from BFD, what
> would be the point of still using it over Gold or LLVM's LLD?
>
> It's the same argument I see with gcc. One of it's huge selling points
> is the plethora of targets it supports. If you go ahead now and cut
> out all targets except for the current mainstream targets, you are
> removing one huge advantage that gcc has over LLVM.

If people would step up, it would not be such an issue.
Take a look at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 .
All of the unconfirmed bug reports linked against this meta-bug about
a possible security in generated code.
Yes most of the targets that are left are in-order and won't have this
issue but it just shows which targets are not being maintained.
This bug report shows what targets are have actual maintainace.  And
people can't complain about their favorite target getting removed if
it has an obvious possible security hole happening.
Also you can see there are some "non-mainstream" targets which have
been fixed including m68k and xstormy16.

Thanks,
Andrew


>
> > Some of these architectures happen to have Linux support too, for embedded
> > applications.  All the world is not Linux.  And all the world are not
> > distributions either.  Freescale S12Z is the most recent addition I
> > believe, and has no gold support AFAICT.
>
> Yep. And that's why I think it's better to keep BFD useful for various
> targets and not bother about potential vulnerabilities which don't really
> pose a threat in the real world, e.g. the threat that someone is sending
> a user a manipulated object file and asking them to open it with "readelf"
> or "objcopy" running as root.
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz@debian.org
> `. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[John Paul Adrian Glaubitz]

On 08/08/2018 11:27 PM, Paul Koning wrote:
> I don't quite understand.
> 
> The original discussion seemed to be the removal of the a.out and coff output options specifically for sparc.  In other words, a target which used to support ELF along with some other formats now supports ELF only.

Yep. So you cut out support for the targets sparc/coff and sparc/a,out, the
latter being the target format used by the OBP firmware used on nearly every
SPARC machine.

> There are also targets that do not support ELF.  And I know of no plans to remove those targets, or to remove the a.out support they rely on.  I'm maintainer for one of them.  

The SPARC OBP firmware is a target that does not support ELF which is why
it is no longer possible to build binaries for this target despite being
it an actively used target.

> Nor are there plans to trim the target set of gcc down to "current mainstream targets", whatever that might mean.

Well, yes, I just linked one of those gcc targets - the e500 target - earlier
today. The m68k target in gcc is also constantly under threat because of the
planned cc0 removal. Both the e500 and the m68k targets in gcc are actively
used. The m68k target is still very popular despite its age.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Joel Brobecker]

> > There are also targets that do not support ELF.  And I know of no plans to remove those targets, or to remove the a.out support they rely on.  I'm maintainer for one of them.  
> 
> The SPARC OBP firmware is a target that does not support ELF which is why
> it is no longer possible to build binaries for this target despite being
> it an actively used target.
> 
> > Nor are there plans to trim the target set of gcc down to "current mainstream targets", whatever that might mean.
> 
> Well, yes, I just linked one of those gcc targets - the e500 target - earlier
> today. The m68k target in gcc is also constantly under threat because of the
> planned cc0 removal. Both the e500 and the m68k targets in gcc are actively
> used. The m68k target is still very popular despite its age.

These targets are actively used -- I get that. However, it is only a part
of the equation. What you are asking is that "someone" who does not have
a stake on these targets to bear the cost of maintaining those targets
alive. No matter how active the users are on that target, if no one
steps up to maintain them, these targets become a burden to the rest
of the community.

I don't think you have much chances of getting that decision to be
reverted by arguing how used the target was, simply because it doesn't
address the concern of resource drain. The only way I see it being
reversed is if someone shows that they are capable of maintaining
the target and commits to it.

-- 
Joel

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

[Paul Koning]

> On Aug 8, 2018, at 5:35 PM, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> 
> On 08/08/2018 11:27 PM, Paul Koning wrote:
> ...
>> Nor are there plans to trim the target set of gcc down to "current mainstream targets", whatever that might mean.
> 
> Well, yes, I just linked one of those gcc targets - the e500 target - earlier
> today. The m68k target in gcc is also constantly under threat because of the
> planned cc0 removal. Both the e500 and the m68k targets in gcc are actively
> used. The m68k target is still very popular despite its age.

As others have said, you need a maintainer for a target.  I don't know what the story is for the two platforms you mentioned.  Maintaining an older not so technically demanding platform is not all that hard.  I took on the pdp11 target some years ago because I wanted to make sure it stayed alive, and it still is.  For that matter, I recently did the CC0 conversion for it.  It's not that big a job, and probably easier for the m68k.

	paul

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

[Jeff Law]

On 08/08/2018 06:03 PM, Paul Koning wrote:
> 
> 
>> On Aug 8, 2018, at 5:35 PM, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
>>
>> On 08/08/2018 11:27 PM, Paul Koning wrote:
>> ...
>>> Nor are there plans to trim the target set of gcc down to "current mainstream targets", whatever that might mean.
>>
>> Well, yes, I just linked one of those gcc targets - the e500 target - earlier
>> today. The m68k target in gcc is also constantly under threat because of the
>> planned cc0 removal. Both the e500 and the m68k targets in gcc are actively
>> used. The m68k target is still very popular despite its age.
> 
> As others have said, you need a maintainer for a target.  I don't know what the story is for the two platforms you mentioned.  Maintaining an older not so technically demanding platform is not all that hard.  I took on the pdp11 target some years ago because I wanted to make sure it stayed alive, and it still is.  For that matter, I recently did the CC0 conversion for it.  It's not that big a job, and probably easier for the m68k.
Actually m68k is almost certainly tougher than pdp11, both in terms of
size for the mechanical parts and in terms of complexity.  We've got a
machine description that is 3x larger, multiple condition codes and a
whole lot of effort already spent to do redundant tst/cmp elimination on
the m68k.  Replicating it in the non-cc0 world will be nontrivial.

I'm hoping my son will wrap up the h8 stuff and move on to the m68k.
Regardless of m68k state I want to declare all cc0 ports deprecated in
gcc-9.  A stretch goal is to declare all non-LRA targets as deprecated.
Note this is personal opinion and is not an official statement of policy
or intent by the GCC project.

jeff

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

[Michael Matz]

Hi,

On Wed, 8 Aug 2018, John Paul Adrian Glaubitz wrote:

> What about elfutils for these purposes? I have been told by gcc people 
> that elfutils was supposed to replace binutils in this regard.

You shouldn't believe everything someone says.

Do you want to solve your problem or just argue randomly 
around?  If the former: elftoaout (its even in some distros as is), if the 
latter: please continue, but it won't help the former.


Ciao,
Michael.

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

[Jose E. Marchesi]

    
    > "git log bfd/aoutx.h" if you want an illustration of points I make in
    > my other reply on this thread.
    
     Exactly why I pointed out the need to have an offer to maintain the code 
    as a condition.
    
As a SPARC binutils maintainer, I supported obsoleting sparc/coff and
sparc/aout targets back in 2016.  The rationale after my support was
that Solaris, GNU/Linux, and the other OSes running on the little sparcs
(VxWorks, RTEMS, etc) are all ELF targets.  It is reasonable to expect
that any remaining aout-based systems still in operation will be using
an old version of binutils, if they use GNU binutils at all.

So the SPARC bootloaders operate on a.out images... as Alan and others
already pointed out, there are several possibilities:

a) To use an older binutils version to link the image with the
   bootloader.

b) To link to ELF and then use elftoaout [1] or a similar tool.

AFAIK Fedora successfully used elftoaout to generate the stage1 images
until they deprecated the SPARC support back in 2012.  Debian
distributes elftoaout as part of the sparc-utils package [2].

There is of course a third option: to put back the sparc/aout support in
binutils, and maintain it... well.. in principle I stand with my 2016
rationale and I won't be working on sparc/aout on my own time.  So
unless my employer decides to sponsor the sparc/aout support in binutils
(I already made some inquiries) I won't be maintaining that code.

[1] ftp://sunsite.icm.edu.pl/site/linux-sparc/elftoaout/
[2] https://packages.debian.org/wheezy/sparc-utils

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

[John Paul Adrian Glaubitz]

On 08/10/2018 11:57 AM, Jose E. Marchesi wrote:
> AFAIK Fedora successfully used elftoaout to generate the stage1 images
> until they deprecated the SPARC support back in 2012.  Debian
> distributes elftoaout as part of the sparc-utils package [2].

Meh, I'll just leave it to GRUB upstream now to resolve this problem,
I assume that Eric will soon run into the problem as well once the
toolchain on Solaris gets updated.

> [1] ftp://sunsite.icm.edu.pl/site/linux-sparc/elftoaout/
> [2] https://packages.debian.org/wheezy/sparc-utils

FWIW, sparc-utils isn't part of an official Debian release, it's
just part of Debian Ports. But we're working on building the package
everywhere now.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913