On Mon, 2010-07-12 at 16:03 +0100, Paul Brook wrote:
> > 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.
>
The reason why a new triplet is required is that config.guess needs to
generate it when running native. Config.guess is the only way to
communicate the information needed for a native compiler when no other
information is communicated on the command line, and it only reports a
triplet. Yet it's essential that the right ABI gets selected in this
case, or you'll have a non-functional toolchain. That is, on a native
machine
.../configure --prefix=...
must build a native compiler that conforms to the native ABI of the
machine.
> 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.
>
Indeed. The draft ACLE specification has one __ARM_PCS_VFP, but that
document hasn't been published yet.
> > 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).
FPA isn't legal in the EABI. Maverick is incompatible with the
Hard-float variant. I accept your point, however, that maybe this
should be conveyed more clearly in the name, but in reality, VFP is now
*the* way to do hardware floating point on ARM.
>
> > 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.
FWIW, I can't say I like the idea of using the vendor field for this,
but I don't have a particularly strong opinion on that matter. It is
true that the vendor field in the triplet is essentially useless today
for Linux; but I'm not (yet) convinced that (ab)using it for ABI variant
information is the right way to go.
>
> 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.
>
The change, I think, was to stop magically changing the ABI rules based
on the CPU name, not to ignore it completely: I'd expect xscale to
cause v5 code to be generated (unless specifically overridden with
--with-cpu).
R.
