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
|

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 - [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
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
Reply | Threaded
Open this post in threaded view
|

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

Andreas Schwab-2
In reply to this post by John Paul Adrian Glaubitz
On Aug 08 2018, John Paul Adrian Glaubitz <[hidden email]> 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, [hidden email]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."
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 John Paul Adrian Glaubitz
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
Reply | Threaded
Open this post in threaded view
|

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

Paul Koning-6


> On Aug 8, 2018, at 2:27 PM, Maciej W. Rozycki <[hidden email]> 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


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 Maciej W. Rozycki
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 - [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 Paul Koning-6
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 - [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

Paul Koning-6
In reply to this post by John Paul Adrian Glaubitz


> On Aug 8, 2018, at 5:23 PM, John Paul Adrian Glaubitz <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Andrew Pinski-3
In reply to this post by John Paul Adrian Glaubitz
On Wed, Aug 8, 2018 at 2:23 PM John Paul Adrian Glaubitz
<[hidden email]> 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 - [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 Paul Koning-6
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 - [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
> > 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
Reply | Threaded
Open this post in threaded view
|

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

Paul Koning-6
In reply to this post by John Paul Adrian Glaubitz


> On Aug 8, 2018, at 5:35 PM, John Paul Adrian Glaubitz <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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
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 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.
Reply | Threaded
Open this post in threaded view
|

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

Jose E. Marchesi-2
In reply to this post by Maciej W. Rozycki
   
    > "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
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/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 - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
12