Discussion:
Recent removal of a.out and COFF support for sparc
(too old to reply)
John Paul Adrian Glaubitz
2018-08-07 10:51:17 UTC
Permalink
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 - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Gunther Nikl
2018-08-07 12:58:43 UTC
Permalink
Post by John Paul Adrian Glaubitz
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
Vladimir 'phcoder' Serbinenko
2018-08-07 15:04:09 UTC
Permalink
I can change code to do conversion to coff ourselves.

вт, 7 авг. 2018 г., 12:56 John Paul Adrian Glaubitz <
Post by 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
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
_______________________________________________
Grub-devel mailing list
https://lists.gnu.org/mailman/listinfo/grub-devel
John Paul Adrian Glaubitz
2018-08-07 15:16:21 UTC
Permalink
Post by Vladimir 'phcoder' Serbinenko
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 - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
John Paul Adrian Glaubitz
2018-08-07 15:56:58 UTC
Permalink
Post by John Paul Adrian Glaubitz
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
Post by John Paul Adrian Glaubitz
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=8e415ce8fee234cd86f29d8f4ebbbdf0f9c0b031
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Alan Modra
2018-08-08 01:55:29 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by John Paul Adrian Glaubitz
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
John Paul Adrian Glaubitz
2018-08-08 09:07:58 UTC
Permalink
Post by Alan Modra
Post by John Paul Adrian Glaubitz
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.
Post by Alan Modra
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.
Post by Alan Modra
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?
Post by Alan Modra
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 - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Alan Modra
2018-08-08 13:16:59 UTC
Permalink
Post by John Paul Adrian Glaubitz
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
John Paul Adrian Glaubitz
2018-08-08 13:45:27 UTC
Permalink
Post by Alan Modra
Post by John Paul Adrian Glaubitz
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.
Post by Alan Modra
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.
Post by Alan Modra
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?
Post by Alan Modra
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 - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
John Paul Adrian Glaubitz
2018-08-08 14:03:13 UTC
Permalink
Post by John Paul Adrian Glaubitz
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 - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Joel Brobecker
2018-08-08 14:20:37 UTC
Permalink
Post by John Paul Adrian Glaubitz
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
Richard Earnshaw (lists)
2018-08-08 15:15:01 UTC
Permalink
Post by Joel Brobecker
Post by John Paul Adrian Glaubitz
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.
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.
Post by Joel Brobecker
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.
John Paul Adrian Glaubitz
2018-08-08 14:41:27 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by Alan Modra
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 - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Cary Coutant
2018-08-08 17:08:38 UTC
Permalink
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
John Paul Adrian Glaubitz
2018-08-08 18:11:13 UTC
Permalink
Post by Cary Coutant
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,
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.
Post by Cary Coutant
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 - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Andreas Schwab
2018-08-08 18:25:55 UTC
Permalink
Post by John Paul Adrian Glaubitz
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, ***@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Maciej W. Rozycki
2018-08-08 18:27:04 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by Cary Coutant
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
Paul Koning
2018-08-08 18:30:57 UTC
Permalink
Post by Maciej W. Rozycki
Post by John Paul Adrian Glaubitz
Post by Cary Coutant
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
John Paul Adrian Glaubitz
2018-08-08 21:26:09 UTC
Permalink
Post by Paul Koning
Post by Maciej W. Rozycki
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 - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
John Paul Adrian Glaubitz
2018-08-08 21:23:02 UTC
Permalink
Post by Maciej W. Rozycki
Post by John Paul Adrian Glaubitz
Post by Cary Coutant
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.
Post by Maciej W. Rozycki
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 - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Paul Koning
2018-08-08 21:27:19 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by Maciej W. Rozycki
Post by John Paul Adrian Glaubitz
Post by Cary Coutant
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
John Paul Adrian Glaubitz
2018-08-08 21:35:40 UTC
Permalink
Post by Paul Koning
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.
Post by Paul Koning
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.
Post by Paul Koning
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 - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Joel Brobecker
2018-08-08 21:53:34 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by Paul Koning
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.
Post by Paul Koning
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
Paul Koning
2018-08-09 00:03:45 UTC
Permalink
Post by John Paul Adrian Glaubitz
...
Post by Paul Koning
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
Jeff Law
2018-08-09 03:43:53 UTC
Permalink
Post by Paul Koning
Post by John Paul Adrian Glaubitz
...
Post by Paul Koning
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
Andrew Pinski
2018-08-08 21:32:51 UTC
Permalink
On Wed, Aug 8, 2018 at 2:23 PM John Paul Adrian Glaubitz
Post by John Paul Adrian Glaubitz
Post by Maciej W. Rozycki
Post by John Paul Adrian Glaubitz
Post by Cary Coutant
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
Post by John Paul Adrian Glaubitz
Post by Maciej W. Rozycki
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
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Michael Matz
2018-08-09 12:34:32 UTC
Permalink
Hi,
Post by John Paul Adrian Glaubitz
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.
Maciej W. Rozycki
2018-08-08 10:59:22 UTC
Permalink
Alan,
Post by Alan Modra
Post by John Paul Adrian Glaubitz
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..
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
Alan Modra
2018-08-08 13:34:53 UTC
Permalink
Post by Maciej W. Rozycki
Alan,
Post by Alan Modra
Post by John Paul Adrian Glaubitz
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..
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.
Post by Maciej W. Rozycki
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
Maciej W. Rozycki
2018-08-08 18:14:37 UTC
Permalink
Post by Alan Modra
Post by Maciej W. Rozycki
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.
Post by Alan Modra
"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
John Paul Adrian Glaubitz
2018-08-10 10:12:03 UTC
Permalink
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 - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Michael Matz
2018-08-08 15:07:31 UTC
Permalink
Hi,
Post by John Paul Adrian Glaubitz
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.
Continue reading on narkive:
Loading...