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 armv7l (see arch/arm/mm/proc-v7.S), so we never know if our host is capable of running armv7hl code.
So we can either build our packages against armv7hl, breaking the assumption that we can find the machine type from uname (basically adding a hack that armv7hl is compatible to armv7l).
Or we could build our packages against armv7l which is what the kernel emits (good!), but would diverge from how Fedora and Meego call their packages.
We're currently not sure which path would be the better one to walk down on. What's the rationale from the other distro folks here?
Alex
On Sep 30, 2011, at 8:11 AM, 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 armv7l (see arch/arm/mm/proc-v7.S), so we never know if our host is capable of running armv7hl code.
Bzzzt! rpm hasn't usesd uname(2) solely to determine arch for all of this century.
So we can either build our packages against armv7hl, breaking the assumption that we can find the machine type from uname (basically adding a hack that armv7hl is compatible to armv7l).
Or we could build our packages against armv7l which is what the kernel emits (good!), but would diverge from how Fedora and Meego call their packages.
We're currently not sure which path would be the better one to walk down on. What's the rationale from the other distro folks here?
I propose -- in order to move this discussion forward faster than distro consensus -- that other body parts be used as as signifiers for CPU capabilities on ARM.
Specifically leg = Little Endian GNU hip = Hardly Intensive Prothesis The avoidance of any common letters of the alphabet will speed up arch identifictaion without the necessity of hand crufted assembly for strlen(3): any letter can be randommly chosen in any order to compare from each set of identifier strings and compared with exactly the same result as comparing the ful string.
hth
73 de Jeff
That we fix rpm to deal with it. We have a preliminary patch in fedora that changes the uname result for hard for we need to make sure that someone can still run a softfp port on the same hardware
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 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).
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
Am 30.09.2011 um 20:27 schrieb 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 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).
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.
So declaring armv7hl as compatible to any armv7l host system seems like the way to go then :)
Alex
On Fri, 2011-09-30 at 14:27 -0400, Chris Tyler wrote:
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 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).
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.
btw, I'd like to add a +1 to Chris' summary here. I would *love* to work with the OpenSuSE folks to standardize as much as we can.
Jon.
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
-
Alexander Graf -
Chris Tyler -
Dennis Gilmore -
Jeff Johnson -
Jon Masters -
Paulo César Pereira de Andrade