Followup on ARM Minisummit at 2011 LPC
dann.frazier at canonical.com
Thu Oct 6 18:43:27 UTC 2011
On Thu, Oct 06, 2011 at 03:20:16PM -0300, Paulo César Pereira de Andrade wrote:
> Em 6 de outubro de 2011 14:38, Jon Masters <jcm at redhat.com> escreveu:
> > On Tue, 2011-10-04 at 00:41 -0300, Paulo César Pereira de Andrade wrote:
> >> For now I have been only considering gcc as compiler
> > I think, realistically, so have we. But I'm open to rethinking that.
> The problem is that this compiler apparently only offers two options,
> softfp (not softfp calling convention) by generating code without fpu
> support, and hardfp that only supports float arguments on float
> registers. IMO, the hardfp abi is not something for a distribution,
> but for a "closed" (not necessarily closed source) image, where
> the exact hardware is known before hand, and from Linux pretty
> much only the kernel and a few packages are used.
fyi, I found that this page contains a pretty good explanation of why
we ended up where we are (at least from Debian's POV):
> >> and the link in
> >> infocenter.arm.com appears to suggest that the mapping, to have an
> >> armv7 distro capable of running existing armv5 or older software, would be:
> >> gcc -mfloat-abi=softfp -mfpu=vfpv3-d16 -> tcc /hardfp /nofpregargs
> >> possibly replacing vfpv3-d16 with neon
> >> but the problem is, the tcc (arm C compiler!?) calls softfp what gcc
> >> calls -mfloat-abi=soft, but "now" only supports hardp with what gcc
> >> calls -mfloat-abi=hard calling convention.
> > So, it's true that we're basically saying as far as we believe Linux
> > distributions go in the ARMv7 timeframe, we assume hardfloat and will
> > all be using the newer ABI. Is that what you meant?
> Absolutely not agreeing :-) I have spent some time packaging, and
> got by myself over 3k Mandriva packages built for softfp, but it is mostly
> for "clearing the path", and knowing what is ahead; the same way
> I did go down all the way cross compiling several bootstraps, and starting
> building rpm, and then a few rpms for all toolchain setups.
> One of the major problems I am seeing on this packaging work is
> because I did choose thumb2 (space saving and compatibility are worth it),
> so far I did either fetch linaro patches, tweak options, add -marm to
> CFLAGS and CXXFLAGS, etc, as most packages around expect
> arm instruction set, and few handle thumb2. There were a few other
> tricks, like some (very uncommon) code expecting "char" to be
> always "signed".
> Hardfp abi adds a completely new set of incompatibility in the field,
> that should affect asm in different places, break pretty much any
> jit/ffi around, does not run armv5 or earlier binaries, and all to have
> what? Like 3% (with luck) increase in performance in fpu intensive
> applications, while almost everything else has no benefits. From my
> understanding, it was wrong from start, and most likely caused by
> comparing apples to oranges, err, software float vs hardware float,
> probably also the software float one not using armv6 instructions,
> not "softfp abi" vs "hardfp abi".
> >> > Jon and I have both been talking to Mats and Jeff about LSB already,
> >> > but things have gone a little quiet while we've been concentrating on
> >> > bringup in the last few months. They would definitely be the right
> >> > people to work with going forwards...
> > So...Adam, we need to sync up on this. I would like to have made a
> > little progress by the time we get to Connect next month.
> > Jon.
> cross-distro mailing list
> cross-distro at lists.linaro.org
More information about the cross-distro