Re: Triplet for ARM Linux HardFP ABI

[Paul Brook <paul at codesourcery dot com>]

> Both Linaro and Debian are considering supporting the ARM hard-float
> variant of the EABI, at least as an unofficial port. This ABI is not
> compatible with the gnueabi currently in use for most ARM Linux distros,
> but has a number of performance advantages.
> 
> This means that we need to choose a name for it.

I don't think we do.  IMO there's no reason (other than dpkg lameness) why 
soft-float and hard-float toolchains should have a different  target triplet.  
You can (and people do) already build a hard-float toolchain by specifying
--with-float=hard.

Anything that rely on the that relies on the target triplet to determine hard 
v.s. soft-float ABI is fundamentally broken.  In a restricted environment 
(e.g. Debian package builds) you may have a fixed mapping, and even that's 
liable to fall apart in a multiarch environment. Given you're already making 
vendor specific assumptions, it seems reasomablt to determing the ABI by 
vendor-specific means.

Of course the real solution if to make the check independent of the triplet.  
GCC doesn't currently define a preprocessor symbol for the ABI, but that's a 
separate bug.

> Obviously, it's better
> if it's an "official" name, so I want to discuss it here. I'm aware that
> there is some bikeshedding to do here, but it's better it gets done
> before anybody gets stuck with something else. There are, of course,
> some real practical reasons why one name might be better than another.

> So here are my suggestions:
> 
>    arm-linux-gnueabihf
>     or maybe
>    arm-linux-gnueabi-hf
> 
>      These will match any package that uses arm*-*-linux-gnueabi*.
>      Choosing which variant is mainly a matter of taste.
> 
>    arm-linux-gnuhfeabi
>
>      These will match any package that uses arm*-*-linux-*eabi (as I
>      see gcc itself does).
>
> I'm not sure which is better. I suspect that, either way, a lot of
> things will need to be fixed up.

I think "hf" is wrong. This is specifically the vfp EABI supplement.  In 
principle we should allow for other ABI variants (e.g. FPA, Maverick).

> An alternative would be to use the vendor field. That would be less
> difficult, but it feels like something of a hack to me.

This would be my preferred solution. When all said an done this *is* a hack 
round a deficiency in your build system. I'm reluctant to propagate that into 
gcc.

It's worth noting that a while ago we made the deliberate decision to start 
ignoring the cpu field. Previously configuring for xscale-elf would do magical 
things.  Also notice that blindly configuring for armeb-linux-eabi still gives 
you a little-endian toolchain.

Paul