From owner-freebsd-arch@freebsd.org Mon Oct 23 15:56:03 2017 Return-Path: Delivered-To: freebsd-arch@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 D2105E4E874; Mon, 23 Oct 2017 15:56:03 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B45D874E50; Mon, 23 Oct 2017 15:56:03 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v9NFtsAc028830 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Oct 2017 08:55:55 -0700 Subject: Re: future of sparc64 To: "Ngie Cooper (yaneurabeya)" , Marius Strobl Cc: Mark Linimon , "A. Wilcox" , Gerald Pfeifer , freebsd-sparc64@freebsd.org, freebsd-arch@freebsd.org References: <20171005234149.GE8557@spindle.one-eyed-alien.net> <59D6CA6C.1040502@Wilcox-Tech.com> <20171007174124.GA20810@lonesome.com> <20171010211428.GA51868@alchemy.franken.de> <353165E9-561A-4A4E-9906-3471928C770B@gmail.com> From: Nathan Whitehorn Message-ID: Date: Mon, 23 Oct 2017 08:55:54 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <353165E9-561A-4A4E-9906-3471928C770B@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVYAHeJ/P6fIQ1B9P93khEvMd85+BIdkyZjUyOFl0VHV2qP1EcwVLTJ1ebqyPQtXqZ0BzTgG8n4l1unXnx9d5pCIY1TMkwCtsHM= X-Sonic-ID: C;NgEMpwq45xGvWYlQ3iMJ6w== M;OlBFpwq45xGvWYlQ3iMJ6w== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 15:56:03 -0000 On 10/22/17 22:48, Ngie Cooper (yaneurabeya) wrote: >> On Oct 22, 2017, at 22:47, Ngie Cooper (yaneurabeya) wrote: >> >> >>> On Oct 10, 2017, at 14:14, Marius Strobl wrote: >>> >>> On Sat, Oct 07, 2017 at 12:41:24PM -0500, Mark Linimon wrote: >>>> All gccs > 4.9 fail to build. Looking at the logs AFAICT the failure >>>> is a floating-point exception as soon as the first built binary is run >>>> during the internal testing. >>> The most plausible cause for that is executables and/or dynamic libraries >>> not installing the user trap handlers as specified by the libc 64 psABI, >>> i. e. not call __sparc_utrap_setup(). Do the ports GCCs use their own CRT >>> nowadays? Do they no longer link libc last? Please provide their linker >>> invocation. Also, please provide the backtrace of a minimal program >>> exhibiting that problem. >> An idea occurred to me (after having dealt with building things over, and over, and over, this weekend): since we can’t rely on the ABI on ^/head to be stable, why don’t we produce working dynamic/static toolchains on HEAD-1 in ports, then require them for the areas that can’t bootstrap (yet, or at all?) with clang? We’ve already done that with some of our code that’s been deorbited from base (like rsh, etc). I don’t see why making a toolchain based on a stable ABI for architectures that will migrate or will be killed off needs to be a huge undertaking (politically), and needs to hold us back from making progress using a compiler that implements an almost 7 year old C++ spec. > … and yes, this can be interpreted as “I will do it as long as people don’t bikeshed me to death on the idea”. > -Ngie > I'm not quite sure what is being suggested, but the core problem with this particular thing is that you can't build ports without a toolchain, so there's a catch-22. The only way to break that involves packages -- which we don't tend to provide on the architectures that have the problem! bapt has done some work on getting this to happen (the base/ ports), but the base/gcc port is both out-of-date and doesn't seem to build anymore, which is where I am currently stuck. Any help with that would be really appreciated... -Nathan