From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B0246138334 for ; Wed, 25 Jul 2018 22:19:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 470C3E087B; Wed, 25 Jul 2018 22:19:28 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BEA33E0858 for ; Wed, 25 Jul 2018 22:19:27 +0000 (UTC) Received: from symphony.aura-online.co.uk (154.189.187.81.in-addr.arpa [81.187.189.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: chewi) by smtp.gentoo.org (Postfix) with ESMTPSA id 08E29335CA9; Wed, 25 Jul 2018 22:19:24 +0000 (UTC) Date: Wed, 25 Jul 2018 23:19:13 +0100 From: James Le Cuirot Cc: gentoo-dev@lists.gentoo.org, arm@gentoo.org Subject: Re: [gentoo-dev] [arm17] [PATCH] toolchain-funcs.eclass: Update tc-is-softfloat for new ARM triplets Message-ID: <20180725231913.1acb1477@symphony.aura-online.co.uk> In-Reply-To: <20180725003416.49416d46@sf> References: <20180724230928.30078-1-chewi@gentoo.org> <20180725003416.49416d46@sf> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/oZ37qGwfh=HZdQKnojEjsKZ"; protocol="application/pgp-signature" X-Archives-Salt: 4aaf248a-03db-4b78-affb-6e7357cb2279 X-Archives-Hash: 062e84cd9ba53172f8330543eff96cb6 --Sig_/oZ37qGwfh=HZdQKnojEjsKZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 25 Jul 2018 00:34:16 +0100 Sergei Trofimovich wrote: > On Wed, 25 Jul 2018 00:09:28 +0100 > James Le Cuirot wrote: >=20 > > The triplet will change from armv7a-hardfloat-linux-gnueabi to > > armv7a-unknown-linux-gnueabihf or similar. The function already > > treated the latter as hardfloat but ambiguous triplets such as > > arm-unknown-linux-gnueabi will change from hardfloat to softfloat in > > line with most everyone else. However, we will now check existing > > toolchains to avoid breaking existing systems, if possible. =20 >=20 > [+arm@ CC] I had intended for most of the information to go into the news item but I guess this commit message is the best place for additional background information that may not concern the users so I'll beef it up a bit. > 1. This changelog is not clear if arm-unknown-linux-gnueabi will > change meaning in this commit. Agreed, the wording could be clearer, I will improve it. I was also partly wrong because although tc-is-softfloat did consider arm-unknown-linux-gnueabi to be hardfloat, toolchain.eclass applies the additional armv[67]* condition. The example you gave on IRC was armv7a-unknown-linux-gnueabi so I will mention that instead. > 2. Did Gentoo ever use arm-unknown-linux-gnueabi tuple? I don't see > it in recent profile history. This was wrong as per above but armv7a-unknown-linux-gnueabi was never used either. However, crossdev expands arm to arm-unknown-linux-gnueabi. 17.0/musl also defaults to arm-unknown-linux-musleabi. I'm just trying to cover all the bases. :) > 3. What are existing toolchain tuples? All the ones people use? Yes. Who knows what's out there? ;) I'll clarify that > > --- > > eclass/toolchain-funcs.eclass | 39 ++++++++++++++++++++++++++++------- > > 1 file changed, 32 insertions(+), 7 deletions(-) > >=20 > > diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.ecl= ass > > index cea8949b45d7..f484fffc2664 100644 > > --- a/eclass/toolchain-funcs.eclass > > +++ b/eclass/toolchain-funcs.eclass > > @@ -204,13 +204,38 @@ tc-is-softfloat() { > > bfin*|h8300*) > > echo "only" ;; > > *) > > - if [[ ${CTARGET//_/-} =3D=3D *-softfloat-* ]] ; then > > - echo "yes" > > - elif [[ ${CTARGET//_/-} =3D=3D *-softfp-* ]] ; then > > - echo "softfp" > > - else > > - echo "no" > > - fi > > + case ${CTARGET//_/-} in > > + *-softfloat-*) > > + echo "yes" ;; > > + *-softfp-*) > > + echo "softfp" ;; > > + arm*) > > + # arm-unknown-linux-gnueabi is ambiguous. We used to > > + # treat it as hardfloat but we now treat it as > > + # softfloat like most everyone else. However, we > > + # check existing toolchains to avoid breaking > > + # existing systems, if possible. > > + if type -P ${CTARGET}-cpp >/dev/null; then =20 >=20 > I believe correct way to get cpp for target is > "$(tc-getCPP ${CTARGET}) -E" Good point. I was initially concerned about Clang but I guess we want this to work the same way under Clang and apparently it does define the same macros. > > + if ${CTARGET}-cpp -E - <<< __ARM_PCS_VFP 2>/dev/null | grep -q _= _ARM_PCS_VFP; then =20 >=20 > 4. This magic is hard to follow and reason about. > I suggest moving out autodetection of current setup into another helper. > Bonus point for detection of mismatch of actual vs. intended state. Fair enough, it managed to confused mgorny. ;) > Then we could start warning users about the fact of inconsistency and poi= nt > to migration procedure. And we could have cleaner ${CTARGET} matches agai= nst > what Gentoo expects. Not sure about this. As I've said, I don't want to force users to migrate. Would a warning be too annoying? > 5. you don't use ${CFLAGS} here. I feel we should use them as people do o= ccasionally > override defaults. I considered it but can we reliably get the flags for CTARGET? > > + # Confusingly __SOFTFP__ is defined only > > + # when -mfloat-abi is soft, not softfp. > > + if ${CTARGET}-cpp -E - <<< __SOFTFP__ 2>/dev/null | grep -q __S= OFTFP__; then > > + echo "softfp" > > + else > > + echo "yes" > > + fi > > + else > > + echo "no" > > + fi > > + elif [[ ${CTARGET} =3D=3D *-hardfloat-* || ${CTARGET} =3D=3D *hf = ]]; then =20 >=20 > I suggest using *-gnueabihf. I don't think anything more generic is recog= nized by toolchains > as a hardfloat target. There is also musleabihf and uclibceabihf. Would *eabihf be better? > Also please link to description of what you think canonical hardfloat tup= les are supposed to > be. Upstreams do not agree on the definition. I thought this was basically dictated by our profiles but okay. > > + echo "no" > > + else > > + echo "yes" > > + fi > > + ;; > > + *) > > + echo "no" ;; > > + esac > > ;; > > esac > > } > > --=20 > > 2.17.0 --=20 James Le Cuirot (chewi) Gentoo Linux Developer --Sig_/oZ37qGwfh=HZdQKnojEjsKZ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQKTBAEBCgB9FiEEUo3mvYaRpDkf2i7UIcYyEpxtfeQFAltY92FfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDUy OERFNkJEODY5MUE0MzkxRkRBMkVENDIxQzYzMjEyOUM2RDdERTQACgkQIcYyEpxt feT+aQ//XuZrx9JJsBCBMh8CSToPL5FiIJ7GBkeg7NEq9J5BHgLZk1SPgM6XhMDf RWwbdii2rIzd/qi+wWqUhHQHxEpUAcUd5iy2ripbXHaKilKRp5zP3hXIYC1WaFy4 29Po95qmRWvf938NFh2n7KAvDVleJCGzk+eHo+4uLalkLK7EHY/gn7OoLALPn6cC otoxNf8jXXXCzzxmJJk7MtjIYTaS12Eezj8+s5HaHJbA1+ZB1RFhsU3yj9aGVRlG wGJMD/c0MWkNJ12jedWlcV/khkjJ2sgGCOrS7+rbKve6TEPdY3GeWyQxkjfuTb2U /Vk0ir20mqykzlbIdnUaapLrDsiLCp7owoV/h+bRXi81mGqboqpef3kH8X7gLcQD yOUOYVe9CIFzNtmzmThrAVapsD7JjdnruoniZDxdL29190/1YyLKAjS3VjKOf6uA vs57uoIx1nN5l+Y15d2qpOM0xlGn8Pw8rj4o6P70IUn0qObWtLuQHfLBOm6xbP7Y b238THEPMnGub2KYgDWSz7aFkSYSiBP0I/cW+3GdMeFHsd2rRVKuRav7a170UwWA ibbIriM8l5cRZaA8THXH5rqNAeMdk+tRr5C92DE5pMhME10ofzo5nZlfQd20JxB/ 2H3nWLa8a6F4M5of9PabgMWN7T8t6qhVEgv3X+HRilDfWhfcL/4= =P8q1 -----END PGP SIGNATURE----- --Sig_/oZ37qGwfh=HZdQKnojEjsKZ--