From owner-freebsd-hackers@freebsd.org Fri Aug 7 20:32:36 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 743929B67A8 for ; Fri, 7 Aug 2015 20:32:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 525C1CCE for ; Fri, 7 Aug 2015 20:32:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (75-48-78-19.lightspeed.cncrca.sbcglobal.net [75.48.78.19]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B9250B926; Fri, 7 Aug 2015 16:32:34 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Cc: Bill Sorenson Subject: Re: Sparc64 support Date: Fri, 07 Aug 2015 12:53:11 -0700 Message-ID: <7311511.ISQt3RZVgq@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 07 Aug 2015 16:32:34 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 20:32:36 -0000 On Wednesday, August 05, 2015 02:10:34 PM Bill Sorenson wrote: > I'm one of probably a few users of FreeBSD and OpenBSD on multiple > platforms left and I thought I'd share some of my experience with BSD on > some of the lesser used platforms. Realistically, the major potential bump in the road for sparc64 is the toolchain. GCC 4.2.1 is getting really long in the tooth and as a Project we want to drop it as our system compiler. I can't tell you when that will happen, but it will eventually. That means that all of our supported platforms will either have to work with clang, or they will need to use an external GCC toolchain (of more recent vintage). Ensuring that one of these routes work for sparc64 will make it much easier for sparc64 to stay in the tree without inhibiting other work. My understanding is that the most recent clang in HEAD can at least build and install on sparc64, but that programs built with it might segfault, etc. If you are up for debugging those issues then that is one approach. I do think that clang works on Linux/sparc64, so that these should be FreeBSD bugs moreso than clang/llvm bugs (but I can't promise that). In theory we have bits in our build system to use an external toolchain for building a system. I haven't worked with them but I have seen others talk about them (e.g. imp@ and bapt@). Getting the recipe down for how to do it and testing that the system works with recent versions of GCC is what is missing there I think (so that there are instructions of 'install port foo', 'stick this in /etc/make.conf', or 'put this on the command line to buildworld', etc.). Of course, testing that the resulting binaries also work correctly would also be good. :) -- John Baldwin