Em 18 de outubro de 2011 17:09, Loïc Minier loic.minier@linaro.org escreveu:
On Tue, Oct 18, 2011, Paulo César Pereira de Andrade wrote:
What is the current state of hardfp toolchain? I ask because softfp, what I earlier considered the most sane engineering option, just builds and works using upstream binutils/gcc, but hardfp requires some hacking; I have been using and building weekly LATEST-4.6 gcc snapshots for quite some time.
It should be pretty good; if you're having issues with FSF GCC, try Linaro's as we've backported some fixes and speed improvements. Support might be better in 4.6 series than in 4.5 series.
Thanks. Currently I am using the same spec file for x86 and arm. But one issue I would like to ask is about openjdk bootstrap.
I adapted fedora java bootstrap procedure to my gcc build, that is, on a x86:
-%<- <<just finished compilation of gcc>>
%if %{with java_build_tar} find libjava -name *.h -type f | \ xargs grep -l '// DO NOT EDIT THIS FILE - it is machine generated' \ > libjava-classes.list find libjava -name *.class -type f >> libjava-classes.list find libjava/testsuite -name *.jar -type f >> libjava-classes.list tar cf - -T libjava-classes.list | bzip2 -9 \ > %{_sourcedir}/libjava-classes-%{version}-%{release}.tar.bz2 %endif -%<-
and on the arm:
-%<- <<unpack tarball and enter gcc build directory>>
%if %{with java_bootstrap} tar xjf %{SOURCE6} %endif
<<configure and build>> -%<-
And it compiled all the java stuff; now I have:
# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/armv7hl-mandriva-linux-gnueabi/4.6.2/lto-wrapper Target: armv7hl-mandriva-linux-gnueabi Configured with: ./configure --build=armv7hl-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-1.5.0-gcj-1.5.0.0/jre --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,objc,obj-c++ --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=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux --host=armv7hl-mandriva-linux-gnueabi --target=armv7hl-mandriva-linux-gnueabi Thread model: posix gcc version 4.6.2 20111019 (Mandriva) (GCC)
This is the first gcc 4.6.2 Release Candidate, the eclipse-ecj.jar is from a x86 computer (noarch bootstrap package).
But I think it is completely "booged", for example, the Mandriva openjdk build is based on the fedora one, but, to get it past of early stage "rewriting" rhino (another noarch package), it was failing with an out of bounds exception, so, I changed:
/stage3/rpmbuild/java-1.6.0-openjdk/BUILD/icedtea6-1.9.7/rewriter/com/redhat/rewriter/ClassRewriter.java like this:
- private static final boolean DEBUG = false; + private static final boolean DEBUG = true;
then, after rebuild, it did print a very large amount of debug, but worked... (that should have triggered some flush somewhere) but did not matter much, because I got to a point where gij would jut core dump, specifically, this command:
/stage3/rpmbuild/BUILD/icedtea6-1.10.3/bootstrap/jdk1.6.0/bin/java -Djava.endorsed.dirs=/stage3/rpmbuild/BUILD/icedtea6-1.10.3/bootstrap/jdk1.6.0/lib/endorsed -classpath /stage3/rpmbuild/BUILD/icedtea6-1.10.3/openjdk.build-ecj/hotspot/outputdir/linux_arm_zero/product/../generated/jvmtifiles jvmtiGen -IN /stage3/rpmbuild/BUILD/icedtea6-1.10.3/openjdk-ecj/hotspot/src/share/vm/prims/jvmti.xml -XSL /stage3/rpmbuild/BUILD/icedtea6-1.10.3/openjdk-ecj/hotspot/src/share/vm/prims/jvmtiEnter.xsl -OUT /stage3/rpmbuild/BUILD/icedtea6-1.10.3/openjdk.build-ecj/hotspot/outputdir/linux_arm_zero/product/../generated/jvmtifiles/jvmtiEnter.cpp -PARAM interface jvmti
Since I recently wrote a jit for arm for my "toy" language, and have a fork (for "playground" hacking) of GNU lightning where I added support for arm, I was aware of issues with the hardfp abi and varargs functions (I still need to add support for hardfp to my jit code, and write a thumb2 jit at some point, but porting a distro from scratch takes quite some time :-)
So, sometime ago I saw this email
http://lists.fedoraproject.org/pipermail/arm/2011-August/001732.html
and just did look a bit more to find
http://sourceware.org/ml/libffi-discuss/2011/msg00075.html
So, I believe I should wait a bit more for things to stabilize for openjdk I guess? Well, I am only trying to make some experiments with building java for the sake of completeness, I do not like, neither use java :-)
Also, since it is early stages I thought it was OK to "cheat" for the sake of experimenting, so, for the softfp distro port, I got java-1.6.0-openjdk running fine after using a java-1.6.0-openjdk-devel for armv5te. And, also tried to "cheat" as apparently fedora already have a java-1.6.0-openjdk for armv7hl, e.g. see
http://aph.fedorapeople.org/RPMS/armv7hl/
but that will just crash on my armv7hl build (maybe I need to add patches to libffi?, not use the one built by gcc?).
Possibly of useful information, gcj would a few times block, and the same did happen on softfp. So, when noticing a build was stuck, I would just run "gstack <pid>" to get it to work; learned that after attaching gdb to all threads just to find out that when detaching it would get out of the dead lock.
I do not know much about openjdk build, or/if it calls varargs functions with float/double arguments, hope not, or things are really broken...
-- Loïc Minier
Thanks and sorry for the usual long email... Paulo