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

[James Le Cuirot <chewi@gentoo.org>]

[-- 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 --]