linux-kernel - Re: [OpenRISC] Removing architectures without upstream gcc support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 26 Feb 2018 13:10:44 +0100
From:   Philipp Wagner <lists@...lipp-wagner.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     linux-arch <linux-arch@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jonas Bonn <jonas@...thpole.se>,
        Chen Liqin <liqin.linux@...il.com>,
        "open list:QUALCOMM HEXAGON..." <linux-hexagon@...r.kernel.org>,
        Richard Kuo <rkuo@...eaurora.org>,
        David Howells <dhowells@...hat.com>,
        openrisc@...ts.librecores.org, Lennox Wu <lennox.wu@...il.com>,
        James Hogan <jhogan@...nel.org>,
        Guan Xuetao <gxt@...c.pku.edu.cn>,
        "open list:METAG ARCHITECTURE" <linux-metag@...r.kernel.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Al Viro <viro@...iv.linux.org.uk>, whitequark@...tequark.org
Subject: Re: [OpenRISC] Removing architectures without upstream gcc support

On 02/26/2018 09:00 AM, Arnd Bergmann wrote:
> On Sun, Feb 25, 2018 at 4:43 PM, Philipp Wagner
> <lists@...lipp-wagner.com> wrote:
>> Am 22.02.2018 um 16:45 schrieb Arnd Bergmann:
>>> While building the cross-toolchains, I noticed that overall, we can build almost
>>> all linux target architectures with upstream binutils and gcc these days,
>>> however there are still some exceptions, and I'd like to find out if anyone
>>> has objections to removing the ones that do not have upstream support.
>>> This are the four architectures I found:
>>> [...]
>>> * OpenRISC is a RISC architecture with a free license and an
>>>    active community. It seems to have lost a bit of steam after RISC-V
>>>    is rapidly taking over that niche, but there are chips out there and
>>>    the design isn't going away. Listing it here for completeness only
>>>    because there is no upstream gcc port yet, but this will hopefully
>>>    change in the future based on
>>>    https://lists.librecores.org/pipermail/openrisc/2018-January/000958.html
>>>    and I had no problems locating the gcc-7.x tree for building my
>>>    toolchains. The port is actively being maintained.
>>
>> It's mostly mentioned in the mailing list thread you linked to, but just
>> for completeness in this thread:
>>
>> The OpenRISC GCC port is maintained and regularly updated to newer GCC
>> versions. It is not, however, upstreamed to the FSF due to a single
>> missing FSF copyright assignment from a developer who has written large
>> parts of the initial port. All code which has copyright assignments in
>> place (binutils, GDB, etc.) has been upstreamed lately.
>>
>> For GCC, Stafford Horne is actively working on rewriting the parts which
>> we don't have the FSF copyright assignment for (and unless something
>> very surprising happens, won't get). [If anyone wants to help, there's
>> GSoC project for it as well:
>> https://fossi-foundation.org/gsoc18-ideas#openrisc-gcc-port]
>>
>> So I'd be very sad if the openrisc port gets dropped from Linux upstream.
> 
> Yes, definitely. What I was really trying to say here is I consider openrisc
> an obvious exception to the 'no more ports without upstream gcc' rule
> because of the above.
> 
> On a related note, has anyone successfully built an openrisc kernel with
> llvm/clang? As we discussed for arch/hexagon/, that architecture is unlikely
> to ever get an upstream gcc port, but like openrisc does have an upstream
> llvm port and they actually use that.

Actually the LLVM port of or1k isn't upstream either. CCing whitequark, 
who might know more about the (non-)plans of getting the backend 
upstream. I also don't know of anyone having tried to build the openrisc 
kernel with LLVM, would certainly be an interesting thing to try.

> I know that x86 and arm64 mostly work with llvm, arm32 works in some of
> the more common configurations at least (not big-endian or older CPUs
> though) and some others probably work as well. I have already build both
> gcc-5.5 and gcc-7.3 for openrisc and uploaded those to
> https://www.kernel.org/pub/tools/crosstool/files/bin/, but if llvm works as
> well, that could be one more reason to try to build a working set of
> clang based cross toolchains.

Philipp