2011/9/30 Chris Tyler <chris@tylers.info>:
On Fri, 2011-09-30 at 14:11 +0200, Alexander Graf wrote:
On 28.09.2011, at 12:50, Steve McIntyre wrote:
On Tue, Sep 27, 2011 at 06:31:51PM +0200, Alexander Graf wrote:
On 27.09.2011, at 18:19, Steve McIntyre wrote:
Out of curiosity, what are you using as a triplet for your
hard-float
port? The discussion at LPC focussed on this to some extent:
http://lists.linaro.org/pipermail/cross-distro/2011-September/000054.html
Ah, nice. I didn't find that mail before. I only found one where the discussion on the target names "armhf" and "armv7hl" was raised, so we named the target "armv7hl" to be compatible with Fedora and Meego.
Fair enough, the internal name doesn't matter much. :-)
Well, it actually does matter because rpm compares it with the output of uname to check if the architecture is compatible. However, if we call it "armv7hl", we are incompatible with armv7l which logically would be missing VFP capabilities. Now, uname unfortunately only emits
The "softfp" abi has the misfortune of making it easy to think it does not use vfp registers, maybe the same way people will confuse "arm9" and "arm11". Nevertheless, currently I am working on a Mandriva port using the softfp abi. Reason of choosing it is because softfp abi allow running unmodified armv5 or older binaries (there may be special cases), and for example it is what you will have if you donwload the "sample" linux images from http://www.arm.com/community/software-enablement/linux.php?tab=Linux+OS+Down... upack it and objdump contents of binaries and libraries, you will notice it uses softfp. Same for most existing pre built toolchains like codesourcery. Aside that, if it were not the fact that gcc is smarth enough to take short circuits avoiding fpr -> gpr|mem -> fpr in calls to "non exported functions", I would prefer to use the --with-float=hard abi. But pathological worst case forcing it to pass arguments in gpr and memory, of a function receiving 8 doubles and returning one shows sub 20% slower in my tests. I did bootstrap Mandriva in all combinations of --with-fpu=vfpv3-v16 or --with-fpu=neon, -with-float=softfp or --with-float=hard, and --with-mode=thumb or --with-mode=arm. My choice ended up being: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/armv7l-mandriva-linux-gnueabi/4.6.1/lto-wrapper Target: armv7l-mandriva-linux-gnueabi Configured with: ./configure --build=armv7l-mandriva-linux-gnueabi --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/lib --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --x-includes=/usr/include --x-libraries=/usr/lib --disable-libjava-multilib --with-java-home=/usr/lib/jvm/java-rpmbuild --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-java-awt=gtk --enable-gtk-cairo --with-cloog --with-ppl --enable-cloog-backend=ppl --disable-libquadmath --disable-libquadmath-support --disable-libssp --disable-libunwind-exceptions --disable-werror --enable-__cxa_atexit --enable-bootstrap --enable-checking=release --enable-gnu-unique-object --enable-languages=c,c++,fortran,java,lto --enable-linker-build-id --enable-plugin --enable-shared --enable-threads=posix --with-system-zlib --with-bugurl=https://qa.mandriva.com/ --with-cpu=cortex-a8 --with-tune=cortex-a8 --with-arch=armv7-a --with-mode=thumb --with-float=softfp --with-fpu=vfpv3-d16 --with-abi=aapcs-linux --host=armv7l-mandriva-linux-gnueabi --target=armv7l-mandriva-linux-gnueabi Thread model: posix gcc version 4.6.1 20110916 (Mandriva) (GCC) I know I already did make my points before, but I still need to explain this from time to time for people that know more what is going on in the packages I already had built, and, well, out of some silence I made some decisions and started packaging and have built a "stage3" with almost all possible build requires...
armv7l (see arch/arm/mm/proc-v7.S), so we never know if our host is capable of running armv7hl code.
Any host with an armv7l kernel is *capable* of running armv7hl code (in v7 [A profile], vfp hardware must be present). Since kernel doesn't dictate the userspace API standard, it's impossible to select hardfp/softfp based on uname -- the kernel will work with either. In fact, we can and do mix the APIs on one system (by fiddling the LD paths and/or using chroot to prevent cross-API linking).
I did take advantage of that by using chroots for the different abi setups, and currently I am working on a fedora chroot, but sans a Mandriva kernel (I cannot help much as so far I have been working remotely), it can run a distro already.
The real question is "what is the API variant of the binaries and libraries installed on the host?", which cannot be answered by querying the CPU or the kernel.
-Chris
Paulo -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-arm+help@opensuse.org