From owner-freebsd-sparc64@freebsd.org Mon Oct 23 05:47:06 2017 Return-Path: Delivered-To: freebsd-sparc64@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 01694E411DA; Mon, 23 Oct 2017 05:47:06 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C823E3574; Mon, 23 Oct 2017 05:47:05 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg0-x232.google.com with SMTP id a192so10918685pge.9; Sun, 22 Oct 2017 22:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=0q5lz4vgOOvYOzOPoUa6ZR0eXqAqv1sEg7B+TV1HUuE=; b=Q26oBTmRY5s9zz4ablTkUKhvf39DyNolacyyqaFb8KcFQBePu645ObX2WVyF/GDGgX hooDNDCVjomnvmHoUbt7d7Xe0C3o6UzUK+hUax2P6QJTcX96gAz026LSYHDRwCc46JGn CcysUzUJdY17zzSSLl2xHrgMYd1cnQ8rfxq2I7nZS3dvyRMAE4DqZBEdPkYlkdrC3VKC J6VROi8MLBicJwLHxh8sULgBYFYbE+H9mhpCBQHqO0s+rNTq0L7GMbEbwfod2iy/JI/e paj2zze/pOKVKNcUeSAMwQEcbpGJnHUE9T7Ag612qWn6ZQTkYb/3hVh49c0LSx9ncs1Q SVlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=0q5lz4vgOOvYOzOPoUa6ZR0eXqAqv1sEg7B+TV1HUuE=; b=PAY9UgAMUYlYoHJCXqzKa/1FTW0g1Nv9noK0yeByMpXPfYsQFPtF0RPhjwe/dg4wUT +oggHrzIyMR7UEn3LorSpEhPdyRlOXNRDCioD/4J1GaAwHYka0uBEf/oBhwkroH6cTSM DBefw8fNoeMOlQXSXbPz9aBhR686zmj575WS6qWqsWGiCQRXKoUyfRUTUh9NYuA/SWFm zS5ygBAbtB5dmZDai0kv8beg3+6hEf7hXCol3paqOvLMr11G00BkeI9AQLe94DNJGNRK G4LG7Z42TGoEGoTWbBextW+SDcoQ5sQ/WG0Bnz7nZ6GHJRl0Sepd6l/ldblztnecsfV+ AZXQ== X-Gm-Message-State: AMCzsaWQ+cGWBjiTVkUcsLE8KeBGOoilaPqa9USauEPROUWn3lhqQeMS 6cQC08uXXIKb1QfEG2Ql7w+UIHx+ X-Google-Smtp-Source: ABhQp+TPlYDcyOlsUs34GSrw1abLBNp0hWu9e9BRO/CwdbFETJDDs/yhgqSb27OqTlNRZ2vzQyqffA== X-Received: by 10.99.51.72 with SMTP id z69mr11083341pgz.317.1508737624995; Sun, 22 Oct 2017 22:47:04 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id 68sm11024471pfx.105.2017.10.22.22.47.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 22 Oct 2017 22:47:04 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6F5B54AF-4860-454F-A1B8-C65D9AA8C288"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: future of sparc64 (was: Making C++11 a hard requirement for FreeBSD) From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <20171010211428.GA51868@alchemy.franken.de> Date: Sun, 22 Oct 2017 22:47:03 -0700 Cc: Mark Linimon , "A. Wilcox" , Gerald Pfeifer , freebsd-sparc64@FreeBSD.org, freebsd-arch@freebsd.org Message-Id: References: <20171005234149.GE8557@spindle.one-eyed-alien.net> <59D6CA6C.1040502@Wilcox-Tech.com> <20171007174124.GA20810@lonesome.com> <20171010211428.GA51868@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 05:47:06 -0000 --Apple-Mail=_6F5B54AF-4860-454F-A1B8-C65D9AA8C288 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 10, 2017, at 14:14, Marius Strobl wrote: >=20 > On Sat, Oct 07, 2017 at 12:41:24PM -0500, Mark Linimon wrote: >>=20 >> 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. >=20 > 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=E2=80=99t rely on the = ABI on ^/head to be stable, why don=E2=80=99t we produce working = dynamic/static toolchains on HEAD-1 in ports, then require them for the = areas that can=E2=80=99t bootstrap (yet, or at all?) with clang? We=E2=80=99= ve already done that with some of our code that=E2=80=99s been deorbited = from base (like rsh, etc). I don=E2=80=99t 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. Thanks, -Ngie --Apple-Mail=_6F5B54AF-4860-454F-A1B8-C65D9AA8C288 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE5bk3FaGcY5rvqmb79YOpJmkwhhUFAlntglcACgkQ9YOpJmkw hhU1YA/9GqhSESf6+PxdqZzHes+zqITzwrGXIMZjdrOrE8N9lRSDVZtFGPva0jWl xuzpUEdHrFtnY7+ByCaA5qgy4yqLck1X82E2IPdUjeGHSzo+b0skonHbYvGPkT/n ow2PkuuLo1XkbiFOpRkSb3MZ3yqut7wIF7WkL5COn0nkyjLsswsfdHnVwNB2Txq4 4cYjzO7RYcjCI6zKZVg38OoV9sKaAG/2/DzJNPW1KIaZjdzmD7AXn+2+Fp3KqmAT vmNNydbPr43tTPQ8AHBRLgVEC4qz9vmXmLArqC86VKWo/S6kewzFtAHL3SH0KYjX bNsNvPV1XyWl7HnVT/0fWmpjv42rnVvd98jmW2GWO+1HxQTQB3BNJlaEHzJTVsGn CkxarkL7hARHnXJ8bzE4Ecn7gLdn3e+KjLm2cesrTJnqdr2iEHrUP50BjrR9bXFN XtFPIGc7sP086PWyeTnx1AGu8BDIsSlmYXJpo28PNqM6HAxjBwW0LL2isAL79YEt Gvitp/IYUKulajlAlycyXFGtBHPTdP6WGaPwgVl1GFDWq7bq8BDUfpc171KaDpfs sY/uSG8ooC/R32mRBXMY2XtywWl6exzYyM/5SEK0cEcyD9qFncbALurJ9/D0X6+Q SJIHRRum1rCp78VGNReKKQJrQeeAc18uUBm5MQQFlA7bYCBN0hg= =Tnci -----END PGP SIGNATURE----- --Apple-Mail=_6F5B54AF-4860-454F-A1B8-C65D9AA8C288-- From owner-freebsd-sparc64@freebsd.org Mon Oct 23 05:48:31 2017 Return-Path: Delivered-To: freebsd-sparc64@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 1CE89E413C0; Mon, 23 Oct 2017 05:48:31 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8ECA3698; Mon, 23 Oct 2017 05:48:30 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x22b.google.com with SMTP id b6so16295183pfh.7; Sun, 22 Oct 2017 22:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=LdiEHQ2mv0kUl9PlBlajQk0kiNfZ7wDP4lX5NWuIQw4=; b=CncEuMeYDTII4PabpgdYEGLOGq/rWYFlIPpTSgeZSEBV8SusQqUP6MXhpm8cmi4XDE 9x061taraxEeuUJ8KuTJ3qrgev7d7r9famcmdpI0McGuubo+I8MdEeP4zw/9xUR94T/v 6jrri6SYpolRUsgsWzNv1tfLOas4lcCLwh+xW8p7nu95z5xI/FnAjPkS8AsDq+p9q8Pz 8dndAoXQy57xewTyhjJ73ZUBbe87RQyyiKqQst3HqtRXGWxnnttTeO03B4jbMtZnTO+H IgWBQptyrjll0q6ebB5npJH6ZtabOZ6/PUyTWuloQnvr0M0o7FVr+YuQk24oom1AyiSY fs3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LdiEHQ2mv0kUl9PlBlajQk0kiNfZ7wDP4lX5NWuIQw4=; b=amhAH2G+eLbJej3UiL75HuKbqQdu7058G0IsoZ7dpjPFWyOrqdhvQdYqwmh8HFL0za bh4a4radq3dK2aejHPmpmozJa/hlYR/4bdwklRezySJINNLEerhRnSY0LuA7FtK0yCko siZ5rpkI5BApRiVHdqj1OrsOw16+ujw5sTvxQPr59cvMX51IG5WW4dMK2lGVjAL57/ZR 9nPZEGLO2fO+LNxiyICaFdYJAy9FYAVc2jaPQOHCE2BPQyMApR98d84AygzCICj2z0Lw XsHBMUpwiO//DS/+jRQbABUajMNHr3uUbtLs09sn1wZoqWwQh3fUNfC8qvTwQq7z7ApQ 2dJA== X-Gm-Message-State: AMCzsaXyuWN/1Eupu1g+Ptezy0+sQ99WCVysHUGFLCBO35GY1CW8cZZQ hAYfzc+vgaXQQVopDDq+MItHjTon X-Google-Smtp-Source: ABhQp+QKfhJ70djMS65Zg1DZYP/z/Kxx22WyDUEGyelMSVzU66nvUXvLKaY+/H1Oja0PKFQmRBTGrQ== X-Received: by 10.99.109.75 with SMTP id i72mr10904352pgc.268.1508737710156; Sun, 22 Oct 2017 22:48:30 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id d12sm11238400pfl.140.2017.10.22.22.48.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 22 Oct 2017 22:48:29 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_BECFF20C-DDF8-4900-A417-329769119FE4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: future of sparc64 (was: Making C++11 a hard requirement for FreeBSD) From: "Ngie Cooper (yaneurabeya)" In-Reply-To: Date: Sun, 22 Oct 2017 22:48:28 -0700 Cc: Mark Linimon , "A. Wilcox" , Gerald Pfeifer , freebsd-sparc64@FreeBSD.org, freebsd-arch@freebsd.org Message-Id: <353165E9-561A-4A4E-9906-3471928C770B@gmail.com> References: <20171005234149.GE8557@spindle.one-eyed-alien.net> <59D6CA6C.1040502@Wilcox-Tech.com> <20171007174124.GA20810@lonesome.com> <20171010211428.GA51868@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 05:48:31 -0000 --Apple-Mail=_BECFF20C-DDF8-4900-A417-329769119FE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 22, 2017, at 22:47, Ngie Cooper (yaneurabeya) = wrote: >=20 >=20 >> On Oct 10, 2017, at 14:14, Marius Strobl wrote: >>=20 >> On Sat, Oct 07, 2017 at 12:41:24PM -0500, Mark Linimon wrote: >>>=20 >>> 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. >>=20 >> 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. >=20 > An idea occurred to me (after having dealt with building things over, = and over, and over, this weekend): since we can=E2=80=99t rely on the = ABI on ^/head to be stable, why don=E2=80=99t we produce working = dynamic/static toolchains on HEAD-1 in ports, then require them for the = areas that can=E2=80=99t bootstrap (yet, or at all?) with clang? We=E2=80=99= ve already done that with some of our code that=E2=80=99s been deorbited = from base (like rsh, etc). I don=E2=80=99t 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. =E2=80=A6 and yes, this can be interpreted as =E2=80=9CI will do it as = long as people don=E2=80=99t bikeshed me to death on the idea=E2=80=9D. -Ngie --Apple-Mail=_BECFF20C-DDF8-4900-A417-329769119FE4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE5bk3FaGcY5rvqmb79YOpJmkwhhUFAlntgqwACgkQ9YOpJmkw hhXJqg/8D0o4xyRPGevVzoN9XsJGlfC9ZBOrfOx6F9Q2N8yGWyn8IH/git4wHFej xw0sshT5ySbmVa0dHqikArzE4pCzAXfGMa3UoZFUT075FZJHOeYqsQsVnKOCWbEo Zj4xW0z2UGxBKG0CnfxoRpIgh3W4Ch8uxE2ZyFmYvuzTa6EQvmHxN0Kh6kPv+6D7 fcS/oVKie8fIjdga5jl/jaRWandq6Nefweo1BZ6yS/0P+KGdL7QU/Vtgat59ILlb rkYYcigagxLHJCY3NraBb/bFwvIwMTjfX5iloIOccjXzKxyZCfWi4aLL+cMvEaIO 6KXsKlRxPnFCqj6edlf5A7lr/Hz8E3+luH2U72FmBgYLf4HD/cXrxelHsxJiSP4R HLXQrI7zuNJCGgUwIbIS9ThGejq/oYGDtao403KPSfiO7z0/k0zY5wvtKtwW8jIi 9GQANY10H5+yFwIUpdRCaPEYKCVjTp1nISrW0w2ZBrQY4lXsvuZ9Ll6kRjB8LsI1 S4EJDjOlFNdoDYwvwnJGShl69pzjAffO8kStInJATP/d4Qz34R5oJubo+LzKRjAG TFcWJrPiQwtfzDpricjWK0i1mdqGOc6JlJ4o/9yjUSywPeqn8zaQn/7/n7123ieH 5xTGcBbxpwJhvVqv9mV02zd9znhDrDNmWj3vgcFTvx1kniy3X5Y= =MoDd -----END PGP SIGNATURE----- --Apple-Mail=_BECFF20C-DDF8-4900-A417-329769119FE4-- From owner-freebsd-sparc64@freebsd.org Mon Oct 23 15:56:03 2017 Return-Path: Delivered-To: freebsd-sparc64@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-sparc64@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the Sparc 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 From owner-freebsd-sparc64@freebsd.org Mon Oct 23 20:40:01 2017 Return-Path: Delivered-To: freebsd-sparc64@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 E7F23E54A96; Mon, 23 Oct 2017 20:40:01 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 938A083C69; Mon, 23 Oct 2017 20:40:01 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id v9NKdrOR022905 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Oct 2017 22:39:53 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id v9NKdqpo022904; Mon, 23 Oct 2017 22:39:52 +0200 (CEST) (envelope-from marius) Date: Mon, 23 Oct 2017 22:39:52 +0200 From: Marius Strobl To: "Ngie Cooper (yaneurabeya)" Cc: Mark Linimon , "A. Wilcox" , Gerald Pfeifer , freebsd-sparc64@FreeBSD.org, freebsd-arch@freebsd.org Subject: Re: future of sparc64 (was: Making C++11 a hard requirement for FreeBSD) Message-ID: <20171023203952.GB51868@alchemy.franken.de> References: <20171005234149.GE8557@spindle.one-eyed-alien.net> <59D6CA6C.1040502@Wilcox-Tech.com> <20171007174124.GA20810@lonesome.com> <20171010211428.GA51868@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 20:40:02 -0000 On Sun, Oct 22, 2017 at 10:47:03PM -0700, 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. To be honest, I've no idea what your proposal has to do with the above, what it actually is about or why rsh(1) would be a viable example in this case given that rsh(1) hardly is a bootstrapping tool. However, ABI changes (the above wasn't about a change in ABI, btw.) are just one good example why an external toolchain would be a PITA as system compiler. Think of when we e. g. turned on TLS in the base compiler configurations after having added TLS support to rtld(1). The next buildworld ensured that not only the compiler used TLS, but also that an rtld(1) capable of TLS will be in place. Now with a similar future change and an external toolchain built on HEAD - 1, some additional magic would be needed to ensure that binaries built for HEAD use the expected ABI and all HEAD components are in sync. Generally, I'm fine with moving to an external toolchain for the system compiler, but only if it will also be the default for x86 so the life of tier-2 architectures won't become even harder - both politically and technically - as it is now. Marius