Mailinglist Archive: opensuse-arm (47 mails)

< Previous Next >
Re: [opensuse-arm] Growing some openSUSE ARMs
2011/9/30 Chris Tyler <chris@xxxxxxxxxxx>:
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+Downloads
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-arm+help@xxxxxxxxxxxx

< Previous Next >
List Navigation