[gentoo-dev] [arm17] [PATCH] toolchain-funcs.eclass: Update tc-is-softfloat for new ARM triplets

[gentoo-dev] [arm17] [PATCH] toolchain-funcs.eclass: Update tc-is-softfloat for new ARM triplets

[James Le Cuirot]

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.
---
 eclass/toolchain-funcs.eclass | 39 ++++++++++++++++++++++++++++-------
 1 file changed, 32 insertions(+), 7 deletions(-)

diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
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//_/-} == *-softfloat-* ]] ; then
-				echo "yes"
-			elif [[ ${CTARGET//_/-} == *-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
+						if ${CTARGET}-cpp -E - <<< __ARM_PCS_VFP 2>/dev/null | grep -q __ARM_PCS_VFP; then
+							# Confusingly __SOFTFP__ is defined only
+							# when -mfloat-abi is soft, not softfp.
+							if ${CTARGET}-cpp -E - <<< __SOFTFP__ 2>/dev/null | grep -q __SOFTFP__; then
+								echo "softfp"
+							else
+								echo "yes"
+							fi
+						else
+							echo "no"
+						fi
+					elif [[ ${CTARGET} == *-hardfloat-* || ${CTARGET} == *hf ]]; then
+						echo "no"
+					else
+						echo "yes"
+					fi
+					;;
+				*)
+					echo "no" ;;
+			esac
 			;;
 	esac
 }
-- 
2.17.0

Re: [gentoo-dev] [arm17] [PATCH] toolchain-funcs.eclass: Update tc-is-softfloat for new ARM triplets

[Sergei Trofimovich]

On Wed, 25 Jul 2018 00:09:28 +0100
James Le Cuirot <chewi@gentoo.org> wrote:

> 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.

[+arm@ CC]

1. This changelog is not clear if arm-unknown-linux-gnueabi will change
meaning in this commit.
2. Did Gentoo ever use arm-unknown-linux-gnueabi tuple? I don't see
it in recent profile history.
3. What are existing toolchain tuples? All the ones people use?

> ---
>  eclass/toolchain-funcs.eclass | 39 ++++++++++++++++++++++++++++-------
>  1 file changed, 32 insertions(+), 7 deletions(-)
> 
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> 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//_/-} == *-softfloat-* ]] ; then
> -				echo "yes"
> -			elif [[ ${CTARGET//_/-} == *-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

I believe correct way to get cpp for target is
    "$(tc-getCPP ${CTARGET}) -E"

> +						if ${CTARGET}-cpp -E - <<< __ARM_PCS_VFP 2>/dev/null | grep -q __ARM_PCS_VFP; then

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.

Then we could start warning users about the fact of inconsistency and point
to migration procedure. And we could have cleaner ${CTARGET} matches against
what Gentoo expects.

5. you don't use ${CFLAGS} here. I feel we should use them as people do occasionally
override defaults.

> +							# Confusingly __SOFTFP__ is defined only
> +							# when -mfloat-abi is soft, not softfp.
> +							if ${CTARGET}-cpp -E - <<< __SOFTFP__ 2>/dev/null | grep -q __SOFTFP__; then
> +								echo "softfp"
> +							else
> +								echo "yes"
> +							fi
> +						else
> +							echo "no"
> +						fi
> +					elif [[ ${CTARGET} == *-hardfloat-* || ${CTARGET} == *hf ]]; then

I suggest using *-gnueabihf. I don't think anything more generic is recognized by toolchains
as a hardfloat target.

Also please link to description of what you think canonical hardfloat tuples are supposed to
be. Upstreams do not agree on the definition.

> +						echo "no"
> +					else
> +						echo "yes"
> +					fi
> +					;;
> +				*)
> +					echo "no" ;;
> +			esac
>  			;;
>  	esac
>  }
> -- 
> 2.17.0
> 
> 


-- 

  Sergei

Re: [gentoo-dev] [arm17] [PATCH] toolchain-funcs.eclass: Update tc-is-softfloat for new ARM triplets

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 5054 bytes --]

On Wed, 25 Jul 2018 00:34:16 +0100
Sergei Trofimovich <slyfox@gentoo.org> wrote:

> On Wed, 25 Jul 2018 00:09:28 +0100
> James Le Cuirot <chewi@gentoo.org> wrote:
> 
> > 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.  
> 
> [+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(-)
> > 
> > diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> > 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//_/-} == *-softfloat-* ]] ; then
> > -				echo "yes"
> > -			elif [[ ${CTARGET//_/-} == *-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  
> 
> 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  
> 
> 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 point
> to migration procedure. And we could have cleaner ${CTARGET} matches against
> 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 occasionally
> 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 __SOFTFP__; then
> > +								echo "softfp"
> > +							else
> > +								echo "yes"
> > +							fi
> > +						else
> > +							echo "no"
> > +						fi
> > +					elif [[ ${CTARGET} == *-hardfloat-* || ${CTARGET} == *hf ]]; then  
> 
> I suggest using *-gnueabihf. I don't think anything more generic is recognized 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 tuples 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
> >  }
> > -- 
> > 2.17.0

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] [arm17] [PATCH] toolchain-funcs.eclass: Update tc-is-softfloat for new ARM triplets

[Sergei Trofimovich]

On Wed, 25 Jul 2018 23:19:13 +0100
James Le Cuirot <chewi@gentoo.org> wrote:

> > Then we could start warning users about the fact of inconsistency and point
> > to migration procedure. And we could have cleaner ${CTARGET} matches against
> > 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?

I don't know where to put the warning yet. It thought of it as a longer-term plan
not as today's change. Still would be nice to have helper today that would tell you
that CHOST tuple has unexpected configuration.

I would plug new helper's output as an 'einfo' into gcc and glibc packages :)

> > 5. you don't use ${CFLAGS} here. I feel we should use them as people do occasionally
> > override defaults.  
> 
> I considered it but can we reliably get the flags for CTARGET?

Maybe not.

On second thought let's not peek into users' CFLAGS. They are too volatile
WRT user settings from emerge run to run. Let's sanitize toolchain defaults here.

> > I suggest using *-gnueabihf. I don't think anything more generic is recognized by toolchains
> > as a hardfloat target.  
> 
> There is also musleabihf and uclibceabihf. Would *eabihf be better?

Good catch! Yes, -*eabihf is better. clang supports at least 
    lib/Support/Triple.cpp:    .StartsWith("eabihf", Triple::EABIHF)
    lib/Support/Triple.cpp:    .StartsWith("gnueabihf", Triple::GNUEABIHF)
    lib/Support/Triple.cpp:    .StartsWith("musleabihf", Triple::MuslEABIHF)

> > Also please link to description of what you think canonical hardfloat tuples are supposed to
> > be. Upstreams do not agree on the definition.  
> 
> I thought this was basically dictated by our profiles but okay.

The whole excercise is to attempt to unbreak clang/gcc/other-distros
interoperability. Is that correct? At least it's how I see need for change at all.

Given that there is no explicit meaning attached to CHOST string anywhere
we need a clear description what hardware/abi Gentoo tries to target.

Profiles don't say anything about the meaning of CHOST string. They just use it.

I'll clarify the question: what do given profile CHOST actually supposed to mean
in terms of toolchain parameters?

Example answers to the following parameters:
- ABI
- FPU ABI
- minimal ARM ISA instruction set (integer)
- assumed FPU ISA

I'll take armv7a-unknown-linux-gnueabihf as an example in gentoo today:
- ABI
  - gcc/clang: eabi
- FPU ABI
  - gcc/clang: VFP
- minimal ARM ISA instruction set
  - gcc/clang: armv7-a(?)
- assumed FPU ISA
  - gcc: VFPv3
  - clang: VFPv3+NEON

What do we do about the VFPv3/VFPv3+NEON mismatch?

Presence of neon at the very least causes glibc to disable
IFUNC handling: https://bugs.gentoo.org/657760 . It's not a bug
on it's own and does not cause the problems (I know of) but it's a
visible difference.

I'll try to add a toolchain page to describe today's Gentoo deviations
from gcc's upstream default.

armv6 answers to the above will be different.

[ not directly related but still a mismatch that will cause problems:
  PIC/PIE defaults between gcc/clang in gentoo differ on arm as well ]

-- 

  Sergei

Re: [gentoo-dev] [arm17] [PATCH] toolchain-funcs.eclass: Update tc-is-softfloat for new ARM triplets

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]

W dniu śro, 25.07.2018 o godzinie 00∶09 +0100, użytkownik James Le
Cuirot napisał:
> 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.
> ---
>  eclass/toolchain-funcs.eclass | 39 ++++++++++++++++++++++++++++-------
>  1 file changed, 32 insertions(+), 7 deletions(-)
> 
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> 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//_/-} == *-softfloat-* ]] ; then
> -				echo "yes"
> -			elif [[ ${CTARGET//_/-} == *-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
> +						if ${CTARGET}-cpp -E - <<< __ARM_PCS_VFP 2>/dev/null | grep -q __ARM_PCS_VFP; then
> +							# Confusingly __SOFTFP__ is defined only
> +							# when -mfloat-abi is soft, not softfp.
> +							if ${CTARGET}-cpp -E - <<< __SOFTFP__ 2>/dev/null | grep -q __SOFTFP__; then
> +								echo "softfp"

Either the comment is confusing or you did it the other way around.

> +							else
> +								echo "yes"
> +							fi
> +						else
> +							echo "no"
> +						fi
> +					elif [[ ${CTARGET} == *-hardfloat-* || ${CTARGET} == *hf ]]; then
> +						echo "no"
> +					else
> +						echo "yes"
> +					fi
> +					;;
> +				*)
> +					echo "no" ;;
> +			esac
>  			;;
>  	esac
>  }

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] [arm17] [PATCH] toolchain-funcs.eclass: Update tc-is-softfloat for new ARM triplets

[James Le Cuirot]

On Wed, 25 Jul 2018 07:03:46 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> > diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> > 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//_/-} == *-softfloat-* ]] ; then
> > -				echo "yes"
> > -			elif [[ ${CTARGET//_/-} == *-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
> > +						if ${CTARGET}-cpp -E - <<< __ARM_PCS_VFP 2>/dev/null | grep -q __ARM_PCS_VFP; then
> > +							# Confusingly __SOFTFP__ is defined only
> > +							# when -mfloat-abi is soft, not softfp.
> > +							if ${CTARGET}-cpp -E - <<< __SOFTFP__ 2>/dev/null | grep -q __SOFTFP__; then
> > +
> > echo "softfp"  
> 
> Either the comment is confusing or you did it the other way around.

It is correct but also confusing for two different reasons and I only
explained one of them. :) If grep finds the given string, that means it
is *not* defined because otherwise it would be replaced with "1". I'll
add an explanation for that too.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer